The current lookup order for Share-tier configuration XMLs (bean "webframework.configsource") lists the following order for the last couple of lookup paths:
This means that a share-config-custom.xml bundled within a module JAR can override any configuration that a customer system administrator has set up in the alfresco/web-extension/share-config-custom.xml file. It does not help that there is a alfresco/web-extension/share-config-custom-dev.xml that could be configured to override such overrides from a module JAR, because the module JAR gets another chance to override the overrides to the overrides of the module JAR...
The Repository-tier lookup order for alfresco-global.properties realizes that the customer system administrator must always be able to override any module configuration by putting alfresco-global.properties AFTER the alfresco/module/*/alfresco-global.properties
The lookup order should always ensure that the alfresco/web-extension/share-config-custom.xml and alfresco/web-extension/share-config-custom-dev.xml are loaded AFTER the equivalent files from any module JAR. This is the way that most users expect configuration precedence to work and would make it consistent between Repository and Share.
Additionally, I would like to submit that the alfresco/web-extension/smartfolders-amp-actions-config.xml is somewhat redundant to share-config-custom.xml and should be loaded prior to share-config-custom.xml to avoid the same kind of override precedence issue.
This has been filed against 201602 GA but looking at source history has always been this way. The problem was only realized by me when a module JAR share-config-custom.xml contained a default configuration for a new remote endpoint which I could then not override with a server-specific value endpoint URL in alfresco/web-extension/share-config-custom.xml