ve.init.target is a global variable that refers to the VisualEditor instance on the page. This is fine, until instead of the instance, you have two.
We ran into issues caused by this when working on DiscussionTools, when both the DiscussionTools reply widgets and the normal VisualEditor tried to control it. Instead of solving it properly (or documenting…) we piled up more hacks on top (rEVEDbcfb250f5648: Ensure that ve.init.target is correct when re-activating an ArticleTarget).
It also causes issues in ContentTranslation, where some code is impossible to unit test without setting up a global target (see e.g. 0b2a839ea9a91e9cc0c1615bfc4528c23374dee0, T220314), and for Flow, which uses multiple Targets on a page and sometimes ve.init.target goes null somehow (T303960).
Any code that needs to call some methods on a Target should be passed one explicitly, instead of grabbing the global one.
We might need to leave the code that writes to ve.init.target intact, for compatiblity with gadgets etc. that already use it (it's also nice to have for debugging), but we should never read it in our code.
Remaining uses:
core (lib/ve/src)
- ve.ui.CommandHelpDialog, for working out which keyboard shortcuts have been registered
ve-mw
- Users of getWikitextFragment (and getContentApi/getLocalApi), which needs to know the current page title, host (via getContentApi) and revision ID to parse fragments correctly. Different hosts is used by ContentTranslation which shows 2 VE instances with documents from different language wikis. If you were able to edit the "source" document, this would expose some bugs but at the moment you will only call getWikitextFragment from one side.