The entire article is from the browser internals angle. The page-writer one comes when we have tools to compile pages into app and layer in user features. The rough path for that is simpler ones first (Sile typesetter and Pandoc), then more exotic ones. An example of the later would be a "print to" modification to a browser that can preserve more content like animations and audio and not be restricted to fixed sized pages.

It is forever backwards compatible. API levels is for the rare few cases where we need to deprecate or break something on the engine side but can apply a runtime fix-up script to replicate the behaviour on the scripting level.

Decode/Encode/Network/Terminal is user-relevant insofar as the set of those are interchangeable binaries. If you want more or less (paranoia, legal environment restrictions) media format support, export or streaming capabilities, etc. those can be swapped out per site without any changes to the engine. What is being considered is to be explicit about expected formats in the manifest so that incompatibilities can be detected.

SHMIF is user relevant insofar as "wasm or low-level compiled code" running as local software can be embedded and controlled by the app, allow-listed by the user.

> No third-party storage, and maybe first-party is optional too (not sure what's the plat for this.. user prompt? explicit action?)

Can you clarify what you mean by this?