I think @fcollonval is (correct me if I’m wrong) proposing a convention to order the keys, rather than requiring that the language itself support key ordering. I actually missed the point that user_expressions is not ordered at the kernel level (probably writing too much in one go!), which is why we use a key convention in the extension, and the expressions getter on XMarkdown cell is ordered.
@fcollonval & @chrisjsewell I’ve had a re-think about my position here, and (aggressively ignoring Notebook 2.0) I’m now leaning towards creating a new user_expressions property that contains the kernel outputs (effectively what’s proposed here). We already enshrine the kernel in other places in the schema, so doing it here also makes sense. There’s nothing to say we can’t later settle on a syntax to embed attachments, e.g.
This is an attachment {{ key-1 }} and this is the result of an expression ${{ 1 + 2 }}
In other words, it’s not the fact that we can “inject” rich outputs that warrants a new cell type; it’s the fact that we want to be able to use kernel outputs to do this. We could look at the attachment-injection as a separate feature that might apply to both markdown and emarkdown cells.
I am slightly more in favour of enforcing the ordering in the schema rather than via keys i.e. not exactly storing the result of user_expressions. Given that the results need to be ordered, let’s properly enforce this, and break from the kernel output in the process.
Both jupyterlab-imarkdown and @chrisjsewell’s proposed extension to nbclient I think are sufficient to demonstrate the concept well, so at this point I feel we would benefit from some wider input from the community (in particular long-standing contributors to Jupyter) to get a sense of where things should go.