Lars,
...
4) the next ACPI.PSD is in the queue. Do you think it is sensible for the OS4 team to offer patches to ACPI.PSD to make it work with their kernel ad infinitum ?
...
So here is a real-world example why alternative approaches may be worth pursuing.
I have directly benefitted by subscribing to the Arca Noae's DRIVER package, thanks to that I now have a pretty stable SMP environment, although (and this is the big enough of a justification in my mind) of the total of 6 CPU cores I can only boot the machine up with 5, otherwise I end up with the dreadful "PMSHELL blue screen". Having logged a ticket with support organization it was prompty written of as a "known PMSHELL issue"...hmm...so really?...no further debug, no additional follow-up, just a plain "...can't be fixed..."? And this is for software that I actually paid money for...
Now, from my point of view, I am literally locked-out of using nearly 20% of my computing power simply b/c the current de-facto SMP solution won't let me do it. I'm not saying that this is the SOLE reason...heck, I am no os2ldr/krnl/PMSHELL guru, but as long as I have apparently reached the end of the road in one approach I will pursue others if they arise so that maybe in the course of testing/researching I will learn something and maybe someone else in our tiny community will benefit from.
Beyond just that very selfish reason above, here is a more precise one: if the /ST=0 parameter in the ACPI.PSD drive does in fact get ignored, and the authors have set some arbitrary value for the size of the stack, then I would consider this to be a defect. So if the OS4 team patches the binary to actually correct this behaviour then I'm actually questioning why the "core" OS2 maintainer team refuses to fix the code itself?