...

(should be done in this order, mostly, and with one Jira per step unless specified otherwise)

SimpleOrderedMap (the subclass of NamedList) shall actually implement Map.  

"javabin" encoding shall decode all map data as a SimpleOrderedMap (vs. say a LinkedHashMap) thus allowing "javabin" consumers to compatibility read a SimpleOrderedMap or Map without differentiation to the calling code casting as one or the other.  Even SimpleOrderedMap is a NamedList, thus the calling code might cast to that type.  This should be configurable, particularly for Solr 9.9.  If "javabin" is retained even longer term (not yet replaced with CBOR or...), this decision might be reversed as we reduce casts to NamedList/SimpleOrderedMap, instead preferring Map.

NamedList.findRecursive: deprecate and stop using.  It assumes NamedList; doesn't know about Maps.  Obsoleted by NavigableObject.  One Jira & PR.  Could backport to 9x.

Minor: Use Java 17 "sealed classes" to insist the NamedList type hierarchy is exactly what we want; no surprises.

Change NamedList instantiations to SimpleOrderedMap as appropriate; probably many places.  This is Solr 10 only; it can affect backwards compatibility.  One Jira & PR(s); don't combine with anything else.

Disallow direct/obvious NamedList instantiation, requiring an alternative like a factory method or another subclass.  This forces the developer / call-site to determine if they truly need repeating keys.  One Jira/PR.  Useful to add to Solr 9, with deprecations of the current constructors.

Make the above "public interface" API change.

Solr shall read configuration at a root level (e.g. for PluginInfo from ConfigNode from solrconfig.xml) as a SimpleOrderedMap (not NamedList), with new enforcement of unique keys here (not for SimpleOrderedMap generally).  Plugins that use repeated keys will need to change their configuration strategy, like to use an array.  This will not change interpreting "lst" in XML Solr configuration as anything different, as those elements are nested, not at root configurables (e.g. not for requestHandler or queryParser or...).

Compatibility, Deprecation, and Migration Plan

...