I can reproduce this problem in 4.1, but not with 4.0, leading me to suspect that it is probably caused by the changes in
SOLR-4063 to initialize SolrCore's in parallel.
adding coreLoadThreads="1" to the <solr/> element in solr.xml seems to be work around for this problem, (reinforcing my suspicion) but it may not be a complete work around since that should just make the order of operations deterministic – any impacts of later cores on earlier cores should still be evident, but even if i re-order the cores in your test case, i see no problem using coreLoadThreads="1".
I attempted to create a more trivial example of this problem by having multiple cores refer to lib paths with different dir names containing different stopword files with the same name (my motivation being to create something that could be used in a junit test w/o needing to build special jars) and could not reproduce the problem ... which confuses me.
my current best guess is that maybe the problem is caused by a combination of concurrent SolrCore/SolrResourceLoader init and the "reloadLuceneSPI()" hook in SolrResourceLoader ... i'm looking at NamedSPILoader.reload and thinking that doesn't look thread safe – but i'm not sure if it's expected to be?
I tried a quick experiment of modifying NamedSPILoader.reload to be synchronized, on the theory that the cause of this problem was interleaved requests to that method from multiple threads that where reading "this.services", processing it, and then writing a new "this.services" in a "last thread wins" fashion... but that didn't seem to solve the problem.
The more i look at NamedSPILoader, the less i understand it and how it's used in the context of Solr ... because it's not clear to me how classes using NamedSPILoader, which are themselves loaded by the "webapp classloader" (ie: in the solr.war) ensure that the correct SPI Service is returned in the context of a child classloader in situations where there are multiple child classloaders (ie: SolrCores) that might have conflicting SPI classes. From what i can see, if classloaderA and classloaerB each load their own (possibly differnet) copy ICUFoldingFilterFactory, they're both going to collide in the LinkedHashMap that NamedSPILoader maintains ... right? Is this related to the current bug, or is this perhaps a diff bug?
(or maybe i just understand SPI even less then i think .. which is not much)