When developing / porting extensions, care needs to be recognised that extensions developed for use in RetroLab, and perhaps even ported equivalents of classic notebook extensions, are not necessarily appropriate for use in RetroLab / new notebook if the extension relies on panels, toolbars, etc etc, that form part of the JupyterLab UI.
I suspect there is also a tendency for JupyterLab-first thinking when porting extensions, which keeps notebook/RetroLab users very firmly in the second-class citizen camp.
Having seen support for classic notebook dropped and users being strongly encouraged to move to Retrolab/notebook v7, I already have the gut feeling that notebook users will be next told “if you want extension support, you’ll have to use JupyterLab”.
The UI for document centric / notebook users is markedly different to the that of JupyyterLab and represents a different way of working. Controls for notebook users need to be provided in the context of the notebook app.
I don’t know if this means that separate extensions will be required, in UI terms at least, for certain extensions, or whether UI controls can be rendered appropriately dependent on context.
Calling extensions “JupyterLab extensions” perhaps encourages this lack of relevance to notebook users. Do we need to redefine “jupyterlab extensions” to mean “extensions used in the JupyterLab UI” rather than “built with juoyerlab framework components”, and then also talk about “notebook extensions” which are built using JupyterLab framework components but extend the notebook app and work in both notebook/RetroLab and JupyterLab UIs via the notebook app/UI.
See also issues such as Collapsible headings incompatible with classic notebook extension · Issue #12400 · jupyterlab/jupyterlab · GitHub wrt “notebook users as 2nd class citizens”.