Ahhh...so I'm going to float an idea here that I have arrived at having personally fought through symptoms such as what you just described, and eventually figure out the relationships at play.
The modern day combination of OS/2 software to support/enable SMP most likely has us all using the ACPI driver, and that by default also means that we have the ACPI daemon managing the CPU/cores according to how you actually configure the system.
What this means is that APCI will attempt to use it's fairly sophisticated logic to enable things such as CPU power saving modes (think of the different CPU Cx states here). Basically these are the PowerManager settings in the acpid.cfg file sitting in \mptn\etc.
Now by DEFAULT the ACPI install has the PowerManager enabled and that also means that ACPI and NOT YOU are deciding what a particular CPU/core should be doing. Heck, on the surface acpid.cfg has enough settings there for you to almost set it up for a nearly seamless "power on when I need it" type of an experience.
....BBBUUUUTTTTT.....that also means that ACPI will insist on being the one who controls your CPU/cores and so subsequently when you are attempting to power off/disable a CPU core using an API call such as DosSetProcessorStatus, it most certainly will, but in the background ACPI will immediately take over and either undo what you just did, or if the system is nearly IDLE it may in fact let that CPU/core stay in disabled status.
This very thing caused me a boat-load of problems b/c on my OS/2 box (4.52, so non AOS install but using the same ACPI release) I occasionally have an OS/2 application that will lock my box (soft freeze, CTRL+ALT+DEL still works to power down) during app startup (I have been told maybe SNAP driver related, I think it is something else), and so I took to using a REXX wrapper to always disable all but a single CPU core before I needed to run such a program. Well, as you can imagine when I moved over to ACPI I all of a sudden was plagued by these soft locks 'once again'...I worked and worked through numerous iterations of configs until I finally discovered that the default ACPI PowerManager settings were occasionally flipping ON one of the just disabled cores and BAM...yup, the lock-up would occur.
Soooo....bottom line here is that on this 24x7 box of mine I do not care at all about how much power that sucker eats up, it is backed up by a 1500W UPS box and stays on all the time, running at full 5.2GHz core speed across all eight of it's cores!
Happy with what I have, combination works for me, but it did require me to disable the ACPI PowerManager.
So what I'm curious about Doug is what that specific error message is that you are seeing? Could it be that DosSetProcessorStatus API was patched to sync it up with the ACPI daemon's logic which is driven by the PowerManager??? That would be fancy, although I doubt that is the case.
Food for thought - I am actually trying to understand the whole ACPI system b/c I'd like to create a little utility that tells us a lot more about what the current hardware configuration, and specifically CPU runtime readings are like, we are talking the Cx core states, the actual frequency different cores are running, heck ACPI is even supposed to give you the ability to see the CPU L1/2/3 cache hit ratios, etc....cool stuff!