Change 248932 had a related patch set uploaded (by Ori.livneh):
Deduplicate identical module registrations

https://gerrit.wikimedia.org/r/248932

Change 248932 merged by jenkins-bot:
resourceloader: Deduplicate module registration conflicts

https://gerrit.wikimedia.org/r/248932

ResourceLoader explicitly did not allow this because modules cannot be uniquely identified by name, no more than a PHP class can be. Implementation can vary regardless of the name. And more often than not, duplicate registrations are not identical. Perhaps even incompatible.

Defining the same PHP class in two deployed repositories would also result in a fatal error (though it might be masked by our autoloader, since we lazy-load class definition files).

I've merged the change to emit a warning instead of fatal error (https://gerrit.wikimedia.org/r/248932) which should suffice in practice (so long we monitor warnings during deployment). This will mitigate outages because front-end run-time degrades more gracefully.

However for the record: The correct order to deploy such changes is not relevant, as much as those changes should not be deployed in separate syncs in the first place. Apply the patches on tin and sync in one broader sync-dir (or scap, or wait for the train, or not at all).

The loosening of this warning does not change that such changes must be deployed in one sync to avoid race conditions, and reduce Varnish cache poisoning.

The "Structure" test suite in MediaWiki detects registration conflicts. However the patches were merged in the correct order. Note that as of https://gerrit.wikimedia.org/r/248932, this suite will no longer catch this problem during development, so we have to fill that back. We don't want to wait until production to discover unintended name conflicts. This has caused problems in the past when wikidata, fundraising and another extension had conflicting versions of a jQuery plugin – which unfolded differently in production due to extension load order.

We can actually throw exceptions in developer mode to increase visibility, otherwise a PHP warning would seem like a safer option.