JupyterLab Front End and a Custom Kernel: What Does the Messaging Protocol Actually Guarantee for Rich Output?

We are building a custom kernel that implements the Jupyter messaging protocol (JSON messages over ZeroMQ channels, with HMAC signing from the connection file) and want it to work correctly with JupyterLab and the classic Notebook front end without either side knowing about the other beyond the wire contract. Assume recent Jupyter Server and ipykernel-era protocol versions; exact version negotiation behavior may vary and we plan to verify against the connection file's fields.

The documented envelope (header, parent header, metadata, content) and the shell, stdin, control, and IOPub channels are clear enough for basic execute_request / execute_reply flows. What is unclear is the boundary around rich output: when a kernel publishes display_data with multiple MIME representations, and when widget state is synchronized, the specification does not appear to fully pin down rendering priority or state-sync semantics, and the two front ends seem free to display the same output differently.

Specifically:

• Is MIME-type priority for display_data left entirely to the front end, or is there a documented ordering a kernel can rely on?
• For a minimal third-party kernel, which message types must be implemented for JupyterLab to consider the kernel fully functional, versus optional?
• How should a kernel behave when the front end negotiates an older protocol version than the kernel implements?