Parsoid's Cite output differs from the output currently rendered in desktop read views. A number of user scripts, bots, and gadgets likely depend on the structure and classes found in current output. But, as part of read views, when we roll out Parsoid's output, we could break them.
Concrete example: Accessibility attributes in Cite output
In this link, @Izno says: I notice that the "up arrow" in VE links pertaining to this discussion do not contain aria-label, which makes them more accessible, as content in CSS is not guaranteed to be read out in accessibility agents. This is a delta from read-mode Cite today. See the DEF reference in my sandbox. There is a similar full span for the other links in the multiple use reference.
The issue at this time seems to be that Cite's JS modules don't apply to Parsoid's HTML. Since Parsoid uses different class names, the JS code that inspects Cite content won't work out of the box. In this specific case, that code looks for .mw-cite-backlink which Parsoid doesn't add.
It is not too difficult to fix up Cite's resource modules to handle Parsoid output, but this is just an example of the larger issue raised earlier..
Possible strategies
Given the experience with media output changes in core, it might be prudent to switch over class names to what the Cite extension uses rather than try to update all the code that are probably referencing these classes. There may also be some impact from some minor HTML structure differences that we will have to evaluate.
Here are some possibilities:
(a) Add a html2html processor that adapts Parsoid's cite output to current output format expected by gadgets. But, in parallel, start an effort to get gadgets, bots, etc. to migrate over to Parsoid's native output so we can eliminate this processor
(b) Figure out what is involved in updating Parsoid's cite output to be a bit more closer to current output to minimize impact on existing gadgets, bots, etc. reduce the effort needed to migrate over to Parsoid -- from an early inspection, a number of clients already have dual-mode code to handle both output, but I doubt on-wiki tools and workflows are Parsoid-ready.
(c) Just embrace Parsoid's output and start an effort to migrate gadgets, user scripts, bots, etc. to be compatible with Parsoid output.
Note that there is no easy path available to us at this time. There are a number of clients, tools, and external users that have come to rely on Parsoid HTML. So our ecosystem is split into two sets of users. So, we need to do a quick evaluation of what our best forward path here is.