A container per thread sounds like the least efficient solution possible.
Not ideal, but not too bad either.
I completely agree with what you’re saying for those other problems you describe. But for the typical node.js webapp, doing the one-container-per-core is perfectly fine.
My app should be stateless and scale by replication. This is the most efficient solution in every possible way.
Containers don't cost meaningfully more than threads unless you create expensive unique resources for each one.
This is way more overhead than threads which can share all of those resources.
Shared process memory isn't the easy memory-consumption win it sounds like, locking is hard to get right, potentially very destructive to the parallel performance that was the point of the whole exercise, and marries you to a single physical box.
Even if you want to take advantage of shared-address-space shared memory you probably want to do it in a more principled way than fork()
One-copy-per-thread and share-by-communicating both give you braindead simple scaling without dealing with that.