I don’t think that adding a couple of ivar in the Fiber is a bad thing, but yeah, the penalty exists.
I think Fibers could be subclassed. I don’t recall anything in the runtime that forbids it.
I’m in favor of adding protected methods to reduce the monkey-patching needed.
Yet two other routes could be:
a) mimic Crystal::ThreadLocalValue for fibers, to have an external hash from fiber => value. you would still need a monkey-patch to release the entries when a fiber finishes.
b) (ab)use the fiber stack to store some data. There is memory available there… I guess it can be used. It would be like reserving part of the stack for additional fiber runtime memory. If so, either that data need to be added as gc root at before_collect or the stackbottom/top need to cover them to avoid collection. Also the stack are stored in a pool and are reused.