Interesting approach. I'm not sure I would rely on it, though. There can be subtle differences in an OS "tuned" for an embedded environment vs. a desktop environment. Embedded environments tend to be more resource constrained. Telling an OS that it is "embedded" could alter the way it allocates and manages resources; potentially in ways that significantly impact performance.
Just like telling an OS that it is in a SERVER environment would alter the way it allocates resources, schedules jobs, etc.
Two simple examples:
In embedded environments, you often don't have any/as much disk to use for "swap"/paging file. You may, in fact, disable swapping and rely exclusively on available RAM to hold all "real" memory. This could needlessly hamstring a desktop machine into NOT exploiting the abundant disk resources available to extend the available "virtual" memory.
In embedded environments, you tend to have fewer network connections (a server tends to have tons of them; a desktop, something in between). TCP connections take up resources -- for every open connection (even if it's a connection being used by "another logged in user" who isn't "active" at the present moment -- like when you "Switch User" without logging off, first). So, an OS thinking that it is operating in an embedded environment might tune the network stack for fewer connections -- at the expense of throughput for the MULTIPLE connections that desktop users tend to exploit.
Personally, I've not seen any need for *any* of the XP updates that I've installed. My machines don't talk to the outside world so the "security updates" tend to have no noticeable impact on performance/operation.
OTOH, I note at least two "bugs" remaining in the "OS" (silly term because many of the "programs" aren't really part of the "OS" per se!):
- hammering on SMB/CIFS shares tends to cause the bandwidth to unexpectedly drop to some ridiculously low level; almost approaching what you could do with a serial port!
- MOVE-ing a folder/file from an external (USB) drive seems to leave a file handle open on that drive. Attempts to eject it afterwards are met with "someone is using that drive" errors.
There are also annoying inconsistencies throughout the UI that the "OS" presents:
- sort order varies based on what is presenting the filelist
- file sizes are sometimes exact, sometimes KB/MB, sometimes KiB/MiB, etc.
- file sizes are sometimes rounded up; other times truncated or rounded down
- you can create a file in a place where it can not be accessed, deleted, renamed, etc. (path length limitation)
- more that I can't recall...