After the discussions of the last year my feeling is that a next generation data format fulfilling the requirements of all major players, and being accepted by all major players, is not exactly around the corner. However, some players feel pressure from the limited namespace in all network, station, and sensorlocation codes. In this situation it would be a pity if in this situation the community and the format consensus broke up because of some moving fast, applying some quick fixes, while others moving slow, but trying to fix the problems of the upcoming 30 years.
However, there still seems to be an easy solution which will not solve the 30 years problems, but, by better exploiting existing formats and definitions, buy some time to get the future right. It is: using the non-capital part of the current SNCL name spaces.
Looking at the standards, I have not seen any document by ISC (for station names) nor by FDSN (for network names) stating that non-capital letters are disallowed for the respective codes, or should be interpreted as aliases of capital letters. Corresponding data fields in seed format (as well as the data fields for location- and channel codes) are, according to Format version 2.4 manual at https://www.fdsn.org/seed_manual/SEEDManual_V2.4.pdf, defined as alphanumeric in ASCII, without restrictions on non-capital letters. Also here I have not found any hint that ASCII #97-#122 should be considered as aliases for ASCII #65-#90. In stationXML, according to https://www.fdsn.org/xml/station/fdsn-station-1.0.xsd, all network code, station code and channel code are represented as xs:string (i.e.: Unicode, a superset of ascii and case sensitive too.)
Thus, the relatively large non-capital part of the *existing* name space, according to *current* definitions, has just not been touched yet.
Thus, if we feel that name spaces are tight, we should start using the non-capital part of the name spaces, and boost the number of possible network names by a factor of 3, and the number of possible station names roughly by a factor of 15 - without modifying any of the formats or definitions which have been in place for the last decade, and probably without modifying any major software package implementing them.
Doing so may help, at least for classical network operations, to keep the community together and to buy us some more time for another trial to develop consensus on a sustainable solution for the further future, for non-clasical use cases and very large n applications.