Basing this standard on Functional Programming minimizes the number of bytecodes that would need to be interpreted to the bare minimum needed for Turing Completeness. Whilst giving it more opportunity for optimizations. Though they may override standard library functions to expose additional machine codes, e.g. arithematic. This approach gaurantees strong backwards compatibility by way of built-in polyfills.
Performing I/O exclusively via function arguments and return values strengthens the boundaries of the sandbox, and using FRP minimizes the impact it has on the interpretor. As for the ease of implementing this I/O all depends on the window manager being targetted, though it would be natural to base the standard upon Wayland as that would naturally translate to FRP.
I leave out of scope any sort of high-level API for building a UI, though low level drawing APIs would be part of the I/O. Arguably this is shifting complexity around rather than removing it all together, but it does mean interactives don't need to pay for the complexity they don't require.
Overall I'd consider this spec trivial to implement, depending on how much optimize.
