I’m not sure what the roadmap for ISO 8601 looks like, and yes, I’ve seen the message stating “at this stage no further technical changes are allowed without compelling reason”.
Still, I’d like to object to the “decision” that season intervals “won't be supported (not initially at least)”, and I would indeed argue that there is a compelling reason to make that change, even late in the day.
In bibliographic data, season intervals are by no means uncommon (one example from the Chicago Manual of Style, 16e, 14.271: “Autumn 1980–Summer 1981”).
These season intervals need to be entered, represented, and processed somehow. Given that YYYY-MM/YYYY-MM and YYYY-SS are valid, YYYY-SS/YYYY-SS is a highly straightforward and not in the least ambiguous or otherwise problematic representation.
(In fact, at least three popular reference management packages, Zotero, biblatex, and pandoc, have been using the YYYY-SS/YYYY-SS notation for some time now – and, frankly, I don’t see what else they could use if they both wish to use the ISO 8601 date format, and need to process season intervals.)
In order to promote the use of ISO 8601 dates in general, it seems highly counterproductive to have to tell potential users they may use it to represent seasons (“do use 1980-23”) but at the same time introduce an exception for season intervals (“do not use 1980-23/1981-22”).
Hence I’d like to invite everyone involved it the decision-making process to reconsider this issue, and, ideally, amend the current draft.