Why?

It's hardcoding an implementation detail of the Go runtime, which is subject to change (and if it did, this library might have non-obvious failure behaviour).

Yes, we planned to update the coroc compiler to generate this value instead of having it hardcoded so it will be more future proof.

Eh, this one seems a reasonable trade-off to me at this point. If you try to handle every potential issue upfront, you'll never release, and this seems entirely fixable down the road. Persistent coroutines is a pretty challenging area to explore (tried this with Lua in a previous venture), and this seems a pretty minor point in that overall complexity. I'm curious, what else have you come across that justifies the "really brittle" conclusion?

You do what you have to do, but as a user, I like to know how things will break and what my options will be. I was curious how it worked, and took a peek at the first file that seemed it might reveal something interesting.

They just seem pretty pointless as a tool in language that already have super-light green threads and good concurrency primitives.

https://research.swtch.com/coro might be an interesting read.

Doesn't answer question "why?"

In other languages they were used coz they were far lighter than native threads but that's not the case in Go

A source-to-source compiler, and a library that copies runtime implementation details, was the path of least resistance. We'd love to integrate this with the Go compiler (`go build -durable`, vs. `coroc && go build -tags durable`), but the compiler is closed and maintaining a fork of Go would be difficult.