The problem is Haiku has already surpassed the goal of parity with BeOS R5 so long ago, it’s impossible to know when it happened.
It has MORE features than R5. It supports NEWER hardware than R5. What does Haiku NOT do, that R5 CAN do? Honestly. If devs had stuck to creating an exact clone of R5 in Haiku, I’m quite sure it would be a moot point today… fulfilled long ago.
But what has happened is “this” got added and “that” got changed and “these” got tweaked. And along the way, “this” stopped working and “that” got regressed and on and on and on.
I would propose two teams. One devoted to JUST Haiku R1 (once it meets all criteria for being as functional/stable as R5, then it’s DONE) and one devoted to JUST Haiku x86_64 (let IT be the one that may never see “R1”, because of endless upgrades and improvements and such).
If 100% R5 binary compatibility (able to run any and all BeOS apps you throw at it) cannot be achieved in Haiku, for whatever reason, then either downgrade it (take out whatever “newer” (better than R5) stuff has been added, that is breaking it from fulfilling that goal) or decide that newer features and less compatibility is an acceptable trade-off and throw it to the masses as complete. I’d also propose that some end users be assigned to torture test Haiku 32 (with an old system running R5, for comparison), to make sure it’s just as stable as R5, in the end.
If newer hardware is causing problems, then stick it on older hardware. The same system, preferably, for a dual boot environment or two separate, identical systems, if possible. Really devote everything you can to finishing R1 and putting it behind you.
[I had a Pentium III system (back when they were modern) that ran R5 beautifully. I could start putting feelers out to get another one for this purpose].
Then put all focus into Haiku x86_64 and HAVE FUN!!!