It would exception anytime the engine ran into the script function/global that wasn't native.
One thing you could do is set developer_mode to a specific value (ie, 88) and this would represent that OS is in fact running.
I had put forth some code which checked the script imports in the loaded map and compared it with the script functions/globals in the current game state (the script exports). Pretty sure the final version of it wasn't in the RC though. Anyway, the hope was to use this to try and gracefully put the player back at the mainmenu when they didn't have the required scripting implementations in their OS that the map said it imported. Using this built in system plus a hard coded change of a known script global would be a sufficient setup considering this is just an external game extension and not a source modification.
The only problem then lies within the scripter to actually have the brains to remember to encase their OS script usage inside a check of "(= developer_mode 88)" or what have you.
Also, the skulls system shouldn't be handled by scripts at all. If anything, they should employ their own settings group like Fire was saying. Since this would be OS specific, you shouldn't put too much dependency in the map's design on OS specific data which doesn't have anything to do with its scenario (which is why the netcode enhancements aren't part of the scenario settings anymore, it's a setting for the user not the map maker). OS has its own mechanisms for editing settings while in-game.
Bookmarks