For the start, I'd probably pick route (1). Once the new version of Sculpt is ready, you could give route (2) a try. Route (3) would make sense if you aspire to foster the interoperability between your system and Sculpt OS.
Thank you Norman, it all makes sense to me. I'll indeed start with (1), and keep an eye out for (2) and possibly (3). For that latter one, re. the fine-tuning of process priorities, a Be-style O.S. would typically want to give great importance to UI responsivness. That is, a "Be" OS would positively require that the mouse pointer must always move at 50 fps no matter the CPU load, and the decorator/window layouter would have (quasi) similar responsivness (this is not talking of the "client" area inside the window, which is a different matter of course, just re. dragging windows around by their decorations, resizing, switching to or killing a process/app and so on), meaning it would have almost as high a priority as e.g. threads in charge of audio playback : in the Be philosophy, audio must not "glitch", but windows must not "glitch" either :-). Historically, I've had that kind of expectation from my "daily driver" for a while (I'm not old enough to have had it from the start of BeOS though, i.e. it started on dual Power-PC @ 33 MHz (be)boxen...!) If SculptOS's finetuning of priorities achieves that, then that will be one more reason for me to go with (3), that kind of "bonus" would be as valuabe as anything else I get from it! Anyway that's a topic for later this year.
Cedric