[aw1621107]

> The interoperability problems came from a design choice they made: they wanted to invisibly swap between OS threads if a blocking call was made.

From what I understand the interop problems are more fundamental than that. The Rust devs wanted zero-cost FFI, but FFI for green threads would necessarily involve moving data between the green thread stack and the C stack, which is not zero-cost. Furthermore, the Rust devs wanted "zero-knowlege" FFI, in that calling code wouldn't need to know it's calling into or being called from Rust. That means that you can't assume whatever is on the other side of the FFI boundary knows how to switch/grow/otherwise handle green thread stacks, and inserting shims to do so would also not be zero-cost.

> and we re-implemented the CPU's stack management in software (invariably slower) because they didn't want to write the logic to grow a hardware stack.

If I'm understanding you correctly, part of the problem is that Rust didn't have a good mechanism to grow stacks. Segmented stacks were abandoned because of their allocations and performance cliffs, and stack copying a la Go is not feasible due to the inability to update pointers to the new larger stack. Rust ended up just using larger stacks for its green threads which kind of defeats a major reason to use green threads in the first place.