So I decided what I want to do for minisphere 4.0. I'm going in a slightly different direction than the original Pegasus ideals. In Pegasus,
everything is a module, including all the standard subsystems. This is similar in design to Node.js. Now in Node this kind of setup makes sense, because it's a primarily designed for servers and you only want your server to load what it actually uses. Node has a LOT of different components built into it that most apps won't even use half of, so it would be wasteful to load up everything in advance.
In all my experience with Sphere, I can't help but feel that the Node.js-inspired design for Pegasus is overkill. It's not a big deal if the engine needs to initialize audio for a game that happens not to play sound, for example. And needing to, say,
require("graphics"); at the top of every file gets tedious, even more so once you start needing other components (audio, engine, fs, keyboard...). In practice all that accomplishes is make you want to write a do-it-all wrapper module to avoid all the boilerplate every time you create a new file. Which entirely defeats the purpose of modularizing it.
This doesn't mean I'm doing away with modules, mind you. Being able to write a self-contained script that's guaranteed not to clash with any other library regardless of what you name your exports? Pure unadulterated awesome. So instead, my idea is for low-level stuff to be exposed globally, as in Sphere 1.x, while the more high-level "scripty" stuff gets put into modules. For example, you can
require("prim") to get convenient Sphere 1.x-like immediate-mode primitives:
https://github.com/fatcerberus/minisphere/blob/sphere-api-v2/assets/system/modules/prim.jsOr
require("link") for Radnen's awesome query library.
For Scenario, you'd require "scenes", etc. That kind of code makes sense as a module, but the core engine functionality is better if it's exposed by default. That's, I think, a big reason for Sphere's high level of accessibility over the years, and I wouldn't want to give that up.