In a threaded environment or even when two plug-ins have the same order and the processing order isn't known up front by the developer then any conflicts are on their behalf. Sure it's a possible "problem" where, when used without care, will introduce confusing results. Though it's very similar to two collectors retrieving data from the scene and appending it to a list. Say one separated out the behavior of collecting Joints from the collector of Meshes but they are just stored in the instance.
Once things start running in a parallel (or unknown order) it's always easier to introduce conflicts. Even when two plug-ins set the same data key on an instance.
It's unavoidable that in those cases some responsibility has to be transferred to the plug-in developer for the gains in speed/possibilities they get at the same time.
That's exactly the kind of thing I want to avoid. I want plug-ins to retain the ability to run simultaneously.
Sure that's a good recommendation, but people will still force an "order" of processing using
order values since not everything can run in parallel. E.g. one might need to set values in a database or encode a video, then await its output/results and doing something else with it. Nice here is that it itself defines the order because we intended it that way, but there will be cases where intentions aren't that clear (or even as much required), like appending to the same list from two plug-ins.
I'd imagine it's just like another piece of data that transfers from the context, like
context.data['"__title_update__"] = True. Where possible I would avoid trying to make additional connections. I wouldn't imagine one plug-in constantly changing the window title (theoretically it could when processing a heavy extractor, then it could even show "percentages").