It seems to me that trying to reimplement BeOS as an open source project may not be the best approach. I guess it really depends on what the developer's goals are.
To me, the desire is to keep using the Be APIs, which I have become pretty familiar with and like. There are a number of features, such as the filesystem and indexed attributes, which I really like. But there are also a number of things about BeOS I'm not too thrilled with. Specifically, poor hardware support. It was never great when the OS was being actively developed by Be, and it is never going to get better.
All of the projects which are trying to keep BeOS alive as an independant OS will eventually have to tackle the harware problem. They need a kernel. And trying to write one from scratch is a loosing proposition at this point. There is a certain critical mass that needs to be attained before you can support enough hardware to be useful to a general population.
I think a better approach would be to use an existing base for the really hard parts, and build on that. Leverage the Linux kernel and XFree86 to get you good actively developed hardware support. Then start layering BeOS-like systems on top of that. Don't worry about keeping it GNU/Linux compable, or LSB compliant. Most of the Linux startup and runtime could be dropped over time as BeOS-like replacements fall into place. Even /sbin/init can be cleanly replaced by simply passing the right arguments to LILO. The fact that the system is Linux-based could eventually be invisible to the user except during the first few seconds of the boot process.
The difference between the two approaches is that one has you working on an OS whose hardware support is rapidly falling behind, while the other lets you work on the fun parts (the MediaKit, ApplicationKit, etc.) while leveraging hardware support work that others are doing. From what I've heard, all the keep-BeOS-alive projects are taking the first approach which I think is a dead end. Is anyone trying the second approach?
An interesting hybrid might be to try and get the low-levels of the OS replaced while maintaining binary-compatability with existing applications ala Wine. I haven't looked closely, but there must be a pretty robust hardware abstraction layer at the bottom of the OS to allow the x86 and PPC ports to co-exist as well as they did. If the code underneath that layer could be replaced with a Linux kernel, hardware compatability should be dramatically increased while providing a usable OS without re-writing the ApplicationKit (which would be a lot of work.) I wonder if anyone has investigated this approach.