What internal coroutine stuff are you hoping to get access to? (Since it's not defined in the manual, I assume you mean assigning something to debug.coroutine?)

I want access to internal coroutine.yield and coroutine.resume stuff

I may be wrong, but I feel like this may be better suited as a question posted on the forums as opposed to using the Issue Tracker.

it's a suggestion, OC internals yelds "bubble", which's normally invisible to user code, but I want a "debug.coroutine" that gives me access to that

If you want you can implement your own bubbling versions of the coroutine functions, however I doubt you'll get access to the internal version since that's used for things java/scala side things. And while some of these things might not be dangerous to provide to the user (how shutdown/reboot and signal pulling work), others would be a very bad idea (how certain function calls are done on the main thread). Oh, and the resume function is part of what prevents code from running too long, so that's the reason revealing that to users is a bad idea.

Aside from all the reasons against given above, I'm missing one major thing in this thread: the "why". What do you need this for that's technically impossible and not workaroundable with how it is now?

What would it actually break?

But why would you need it in the first place? Surely you have a usecase for this.

Playing with OC internals? I wanna "get dirty", so to speak

🎤 WHY DON"T YOUUUUUIOOOOOOH just MODIFYIIIIIII bios.luAAAAAAAAAAAAAHHHH? It's possibleeeh, you should triiiiiiiiiiie it sometimesssss.

Closing due to lack of convincing arguments.