Thank you very much for the praise! It makes me warm and happy inside.
Thanks also for the nice feedback on Tethered!
I’ll note, for the record, that “full CSS support” may be a bit of an overstatement. All CSS properties are indeed forwarded to the web browser, but only if the player decides to use a javascript interpreter. The Å-machine will eventually run on 8-bit hardware, presumably without much CSS support at all, which is why the Dialog manual specifies that all style tags are hints, and can be ignored by interpreters.
I concur with @PaulS that (narrate leaving $ $) provides some of the functionality. There’s also (narrate failing to leave $ $). I also concur that more thorough NPC handling would have to be in place before travel connectors could be supported to a wider extent.
But I fully agree that the liminal spaces between rooms are an important part of parser game geography, and deserve attention both at the story and library level.
I am wary of this. All web-related functionality (currently CSS and hyperlinks) is optional for interpreters, and the manual makes a point of telling the author not to rely on it. This is to ensure that Dialog games will remain playable for a long time, as Inform stories have been (and still are). Platforms and features come and go. Javascript changes all the time, and browser compatibility is frankly a mess. Hence the need for a simple, consistent, well-specified interface to carry the actual story, with an optional layer of bells and whistles and graphical presentation on top. As soon as there is a way for the actual game logic to escape into the presentation layer, then forwards and backwards compatibility is compromised. Would you trust a Vorple game to be playable in ten years? Twenty? What about a plain Z-machine game? And if story code has direct access to network communication, that opens the door for online-only games, and those are even more ephemeral.
This would have to be balanced against the need for a strict ordering of rule definitions. There is currently no limit on the number of source code files in a project, but it is critically important to always provide their filenames in the same order on the commandline. The rule definitions in earlier files supersede those in later files. Therefore, in my opinion, it seems sensible for authors to restrict themselves to one file of story code, one file of library code, and possibly one or two small configuration files that go at the very top, controlling global options (e.g. is this a debug build, or a pre-release for testers) that the story code can react to. But there is no technical limitation.
If you are thinking of incremental builds, I’m afraid performance would suffer too much. The full source code is required in order to determine which predicates are dynamic, which can be invoked using multi-queries, which are known to fail or succeed, what words might refer to which objects, and so on, and all of this information is crucial for generating sufficiently fast and compact Z-code (or Å-code for that matter).
All in all, your suggestions have been food for thought. I have attempted to clarify the reasoning behind some of my design choices. But Dialog is still in beta, and a lot could happen before it stabilizes. That evolution will certainly be influenced by thoughtful comments such as yours.