An hour or two ago, I was looking for information on "One-Core-API" (a touchy subject around here, as I understand it), and stumbled upon an article about the unrelated but similarly named "OneCore" project from Microsoft, titled "OneCore to rule them all: How Windows Everywhere finally happened". It's some fascinating reading and shows how schizophrenic Microsoft was back in The Day and how this led to a lot of compatibility issues and duplication of effort. However, what caught my attention the most was on page 2, in the section about development of the NT 6.x kernel:
After reading this, I was reminded of the fact that I never really wanted XP to be supported forever; I just want new versions of Windows to stop sucking. Pretty much everything that we hate about the NT 6.x family has nothing to do with the kernel itself. There's no reason why an operating system based on NT 6.x shouldn't be able to support animated wallpapers, or treat admins as owners of the "Program Files" directory, or remember every program that can open files with a particular extension.Windows NT had grown sprawling and complex, with many different interdependencies between components. Microsoft was discovering this made it very hard to predict the impact of changes to the core operating system. Work in one area would unexpectedly have impact on other parts of the operating system, making isolated development impossible.
The plan with MinWin was to repackage and reorganize the operating system to untangle these interdependencies and create an operating system that was much more amenable to rapid innovation without knock-on effects... The interdependencies were particularly acute in areas such as the shell and the browser. These are high-level components, but low-level components often took dependencies on them. Taking these dependencies wasn't elegant, but it was often convenient. Such functionality was useful and also efficient, as it meant reusing the same code and saving on both disk and memory footprint.
The MinWin project painstakingly analyzed the various dependencies within Windows and broke the operating system down into a bunch of components. These were strictly layered to ensure that low-level components never depended on higher-level ones. Dependencies had to strictly flow from high level to low. That way, high-level parts could be safely modified without breaking lower-level parts and without those changes rippling to the broader operating system.
The APIs themselves were also broken down and divided into much more focused units... The MinWin work first shipped in Windows Vista. Subsequent releases have followed its principles—including the stricter approach to how dependencies are taken—and extended them, with the kernel and individual drivers split up into smaller, more manageable, less entangled components.
More to the point, though, it seems like the NT 6 kernel would be easier to reverse-engineer than the NT 5 kernel. Moving goalposts one last time might paradoxically reduce the workload needed to get ROS 1.0 out the door sooner. Even if it doesn't, it would almost definitely save development time in the long run, since NT 6.x compatibility is generally considered a long-term goal and to finish untangling NT 5.2 would be more of a detour than a stepping stone. However, there are some programs that work in XP but not Vista, and figuring out how to get those running in an NT 6.x clone might eat up some of your gains here.
Furthermore, retrofitting NT 6.x application compatibility onto an NT 5.2 kernel won't do anything for driver support. There is no guarantee that the existence of an actively maintained NT 5.2 clone would spur hardware vendors to resume development of NT 5.2 drivers. Hell, just look at how long it took ATI and nVidia to start writing Linux drivers for their graphics cards. If ROS continues to pursue the "NT 5.2 = ROS 1.0" goal, then there's an extremely high chance of ROS 1.0 being dead on arrival purely due to the lack of compatible hardware at the time of its release. I cannot be the only person to figure this out, and a lot of devs who might otherwise be interested in developing ROS are probably being discouraged for that reason alone. Even if they're not, interest in continued development of ROS will remain low from 1.0 onward if it's dead on arrival, making it take a long time for 6.x compatibility to be added. Again, moving the goalposts one last time might paradoxically attract the developer interest needed to get ROS 1.0 out the door sooner, and will definitely result in sooner delivery of an actually usable OS (whatever version number that might be).
Forgive my ramblings. Caffeine is not an adequate substitute for sleep.
(on the subject of One-Core-API, the forum posts about it are a little bit inconsistent as to why it's bad. What was the final verdict? It was "clean" code, but using it would have drawn unwanted attention from lawyers anyway because the guy who made it also worked on a separate project that used stolen code? Or what?)