I had a idea that is a bit similar, which is a Interpreter header; if the MIME type is not understood by the client software, it can download an interpreter (i.e. a polyfill) (written in HTML or WebAssembly, although your own language might also be a possible alternative); if the client software does understand the format (or the end user already has their own implementation installed, possibly one that they wrote by themself), then it will use that one instead.

> You can hardcode/bake the content into it (like we do today).

While you can, it may make sense to be a separate block so that you can also use the data separately.

> An "URL" could instead be something like an application+datasource pair. The applications are automatically hashed and signed and you can provably verify they haven't changed if you want to. When you request an application to the network, you'll download it from the closest peer (maybe from multiple peers at the same time!). Since it's hashed and signed you only have to trust the signer.

That is a interesting idea, and could work (although making the URL longer, probably). Although it may be useful to add additional arguments too, like command-line arguments/switches (so an implementation could be launched by command-line arguments, too).

This would easily allow an end user to substitute their own application implementation too (by changing the "application" part of the URL), which is also an advantage, and can have a rewrite system to do their own. If it has a hash then you could also cache the application file if wanted (and if you do not have a working internet connection, even to operate on local files that the user gives permission to access), in addition to overriding it with your own implementation, too.

> In fact I've started exploring what that language could look like: https://flame.run/

I like this idea and a few days ago had started to make up the design of something called "VM3" (the name might or might not change in future), which has some similar goals and ideas. However, there are many differences too. VM3 is a binary format (designed to be suitable for both interpreter and for JIT, an static analysis; e.g. there is no way to treat a number from a general register as a return address or vice versa, other than using a static lookup table which is specifically designated as containing program addresses), and all I/O (including the equivalent of JavaScript's Date and Math.random) must be done using extensions. Extensions must be statically declared (cannot be dynamically declared), and an implementation must allow the end user to manage and override them too; polyfills (both included and installed separately) are also possible, too. VM3 can be used with any protocols (HTTP(S), Gemini, IPFS, etc) and any storage media (CD, DVD, etc). (VM3 is also not limited to a specific kind of user interface; you can have command-line, GUI, pipes, etc.)

Someone else also had wrote some ideas about TerseNet. Some ideas of VM3 are similar, and the capabilities of TerseNet could be implemented as a subset of VM3. Multiple implementation types are possible, and possibility of static text, and applications that are only lauched by the user, also has with TerseNet and VM3.

However, unlike Flame which it seem your idea to combine effectively HTML+CSS+JS together, TerseNet and VM3 do something a bit different: parts of HTML (the documentation format) are one format, and other parts of HTML+CSS+JS are the other format; they can easily be separated and work independently.