The point is (AFAIK), that one can create a hybrid haiku image with x86_64 and x86_gcc2 support. Then it will be native support for old binaries.
Not everybody like to see and have a contamined haiku image (there are some legacy-antibelievers here), so the next stage could looks like: outsourcing every bits of gcc2 support to an own package. Then everybody who needs it, can have it, but who don't, can have a vanilla haiku without legacy stuff.
- no emulation or virtualization required, the programs could be run native.
- haiku packages already have "rollback" feature
- first you need to have a x86_64 + gcc2 hybrid image, then trim it to the roots. It is surely plenty work, as for gcc2 ABI support every supporting libs and thing have to be compiled with this feature in focus (FIXME). If somebody starts to working on this field, the most important thing is to keep the contact surface to the host OS (x86_64) so small as possible, so then the work to keep things work could be minimalised. And as long as there is no breaking change in the kernel code, it would work (maybe through R2.... R3 too). We can have a dedicated, clearly defined API in the kernel for this, feature-freezed after R1, so no changes would happen here (idealistic, i know).
- it would work only on x86 compatible hosts, so no gcc2 stuff on ARM or SPARC, etc..
But if we do want to use some kind of container to solve this problem, then somebody needs to port/develop a container system, develop a "rootless X" like seamless integration for gui stuff (you do like drag and drop from tracker, right?) It is really hard to do correctly, if you have an virtualized system (not impossible, check VmWare Fusion Desktop integration, what does the same with windows program on macos). The running programs wouldn't show up in Deskbar, no Drag-and-drop, no window stacking with non-legacy windows, no copy-paste, etc. To support theese features plenty trickery and manpower required. And it would be a castle made of cards, it can breakeverywhere. All the time.
Surely, after developing the container system, the first screenshot about it would pop up shortly as a proof that it is possible, but to do it correctly is an extreme task.
Ofc, nobody would say: don't work on container support for Haiku, it could be some realistic use cases for that, but AFAIK the gcc2 compatibility support not one of them.