No, I think is this good time for advancement as any other, and there was so delay already. And at this time here is a opportunity to make big step with little effort by sepparating what is separated already and only by naming properly and clearing goals:
— 32 bit branch goes to R1 beta1, and gets some maturing cicle;
— 64 bit branch goes to R2 alfa0, and for example receive some updates, wich not accepted in R1 but ready right now (new keymaps with more dead keys, for exmpl.)
Cool idea, vulkan and all the new hardware are more r2 than nothing, even Linux is is avoiding 32 bits, and my oldest amdx2 is x64 … And what can we do rigth now with oldest? It dont need vulkan or transparencies or animations but x64 sure it need
We’d certainly want to have 32-bit compat in 64-bit mode too in the future. If we had that, SoundPlay would be safe 
The only reason we don’t have it yet is that nobody yet had the right combination of time/skill/motivation to work on it.
There are many applications which will likely never be updated to 64-bit even if the author still has the source code somewhere.
So, R1 - 32-bit with BeOS R5 compatibility (gcc 2.95) makes sense. The R1 32-bit branch should receive critical bug fixes but end-users and developers alike should not expect it to be future proof. As a clear example, there should not be an expectation of support for a USB 4.0 protocol if ever such beast comes around.
R1 - 64 bit would be the starting point for R2.
Maybe a 32-64 bridge could be contemplated on the path to R2. However, the danger of having such bridge available would be that some application developers remain forever 32-bit oriented and would not update to 64-bit. Also, without a definite EOL for 32-bit applications during the evolution toward R2, there would be no incentive for fresh application developers to create a modern “SoundPlay”, or “Refraction”, or even a native office suite.
Oh but what about a risc- rasps pi future versions?
Standard way:
32 bit Haiku for 32 bit CPU
64 bit Haiku for 64 bit CPU
but anyway this is for developer to pick.
In
https://download.haiku-os.org/
You can find titles:
Haiku 32-bit Hybrid (Compatible, Stable)
Architecture: x86
BeOS Binary Compatibility: Yes
Compiler: gcc 2.95.3 + gcc 5.4.0
and
Haiku 64-bit (Modern, Fast)
Architecture: x86_64
BeOS Binary Compatibility: No
Compiler: gcc 5.4.0
Separation of Haiku versions already begun. Becouse it is necessity. And, actually here we have two versions of Haiku already. And by acknowledging this we separate and concentrate our efforts in more efficient way: 32 bit R1 receives bug fixes and matures as stable system, and 64 bit R2 progresses further witout holdouts from 32 bit Haiku.
I think there is some progress toward this in the ARM port, but this is lagging behind x86 32 and 64 bit architectures due to those being the current primary focus. I have yet to check this out, due to lack of hardware.
I would love to be able to run Haiku on a Raspberry or Orange Pi. Too bad I lack hardware level programming skills or I would help with the cause 
There’s no reason to not build a 32-bit version of R2, it needs some infrastructure to build/host but nothing on the coding side. I for one still have useful 32-bit haiku machines anyway.
32 bit yes, gcc2 no, there’s difference.
You are still missing the point. R2 will have many changes in API, which means apps will basically need to be rewritten. Not ported, but rewritten. So if we don’t have a 64bit R1, it means the only option for people who want 64 bit for the next few years would be an unfinished system with no apps.
So, we need some migration path. A possible one is having a 64bit R1, and somehow have R2 able to run 64bit R1 apps (with a compatibility layer). We have most of the support for that as we already know how to do hybrid builds.
The option you suggest is a 32bit only R1. In that case, R2 would need to run 32bit apps to provide a migration path. Which means we would need to support 32bit up until R2 end of life, and moreover be able to run 32bit apps on top of a 64bit kernel, something we don’t have support for yet. So in the end, more work for a more legacy system.
Lets rather make 64bit official as soon as we can, so we can completely drop 32bit support as soon as reasonably possible.
This is bad idea. Braking the API from version to version is very bad idea. Even braking binary compatibility is bad idea (32bit—64bit is different story).
Extending API is the way. I understand not compatibile API between R1 and R4, but R1 API must be compatible for R2.
… Who needs 32 bit Haiku now rather than 64 bit Haiku with 32 bit layer for BeOS apps? I would pick second. Time is pass and 32 bit CPU goes to its end, supporting it is supporting end for Haiku.
I see R2 as improved R1, not entirely rewrited.
…And I think you want make too big step for R2 (rewriting everything).
The real size of changes from r1 to r2 is not seeable at the moment. I think it is a good idea to have both, 64bit with support for 32bit apps and a 32bit version. So people with older Hardware have the chance to use haiku and people with new Hardware too. If we have new programs who makes the job of the old ones people will be switch.
Windows do this way too. I have many programs (payed much for them) for 32bit they never would run on 64bit. So i am happy to have this option. On haiku we have the same situation.
I think Haiku has the potential to breathe extra life into older PC hardware, which includes 32-bit machines. I think it’d be unwise to drop 32-bit support anytime soon as some folks see Haiku as the savior of such hardware.
If there is need for this?
I think, older Windows or Linux versions can do this much better.
And Haiku needs much better hardware support to do this at all. Who will write drivers for old hardware?
We have extended the API as much as we can within the constraints of R1 (keeping binary compatibility). The C++ language has moved on, there were some mistakes or rushed things in the BeOS API and these are things we want to fix.
As a result, we don’t want to base R2 on this. The API will keep the good parts, but some classes will be removed or completely changed.
As I said, we do plan to provide some compatibility layer to allow people to run old apps until they are migrated. But we really can’t continue with just extending the API and never deprecating anything. Otherwise Haiku will just stay a clone of a 1990s OS, no matter how much 64bit you try to throw at it.
This is what I talking about, about 64 bit Haiku, there is no binary compatibilty and can not be.
64 bit Haiku can receive all this updates and fixes that 32 bit Haiku can not. Why I sugested separete two Haiku versions even more (by calling 32 bit Haiku — R1, and 64 bit Haiku R2).
But OK, if you do not want to call 64 bit Haiku R2, you can call it R64, R1.2 or something. Main thing this is posibillity to have modern BeOS reincarnaition, in wich we all are interested, I think, not in some old BeOS clone.
You are, once again, missing the point.
If we start making changes this way to the 64bit version of Haiku, it means there will be no way to build apps from the same source as the 32bit version of Haiku. Basically, all apps will suddenly stop working, and it will not be fixed by “just recompile it”. This is the plan for R2 and there is no choice there, we have to move the API forward.
Your suggestion is to just not care and let the 64bit users enjoy a nice modern OS with no apps. I find this not acceptable, so I am trying to explain how making the transition in two steps (first a 64bit version with no API change, then an R2 with 64bit AND API changes + a compatibility layer) will help everyone by providing a more smooth migration path.
Are you really sure you prefer devs to hurry on working on R2, and let all the apps become broken? Would you enjoy an OS with no web browser, no media player, etc? Surely no one needs these…
10 years ago there was a point to have 32 bit Haiku, now it not so much, to say the least. In today’s world 32 bit Haiku looks like some bizarre anachronism. Who will need it? I don’t. We should stop developing it further, make from it beta right now and bug fixing and updating with some servis packs, as long as some one wants to do this. Today main effort must be for 64 bit Haiku and modern updates for it, no matter how you will call this version of Haiku — R1.64 or R2.
… 32bit—64bit is convenient breaking point, there will not be such convenient chanse in the future: small user base, small app base and no binary compatability already and some porting already here are.