a few scattered thoughts:
this innocent-sounding topic is possibly the single most important issue this forum could address, because it is an issue that will impact developers and users alike for decades to come.
a glamce at
https://www.red-bean.com/sgf/properties.html gives me the impression that noble though the sgf effort was, it has become a pig's breakfast, much as many iso standards also are, and the London road system is.
things evolve, and nature has a way of weeding out the unworkable, but that takes time, so it is sensible and timely for interested parties to try to work out a standard that will be both backwards-compatible and forwards-flexible.
sgf seems to be based on a 2-character code; the bit that caught my eye were the lines:
Game Info Properties AN, BR, BT, CP, DT, EV, GN, GC, ON, OT, PB, PC, PW, RE, RO, RU, SO, TM, US, WR, WT
Miscellaneous Properties FG, PM, VW
This might provide the opportunity needed to include additional information that developers want to be able to transmit wihout making the message uninteliigible to old readers. There must be, among that pile of codes, one that none of them use, so by using it, they won't be disturbed - they will merely be blind to it, which is fine, since they don't know what to do with it anyway.
but i don't vote for such a solution, because there's sure to be a squabble about which code should mean what, and there may be instead a much cleaner and more workable approach:-
at the os level, files have a special eof character code - does sgf also have a special "here endeth the lesson" code?
if so, therein - ie after it - lies the best place to stuff whatever information your writer wants to create, which could be as non-standard as you like - whereas this means that not every reader would necessarily be able to read it, i don't see that as a bad thing, for if you write something people like, other writers will copy you, and if they don't, they won't. An analogy might be what happened to English newpapers, which all eventually switched from broadsheet to tabloid - ironically, just before they are about to become extinct!
LZ creates additional point data, which everyone is going to want to display some of (so far, far too much of, in my unhumble opinion!) but there are other writers, such as OGS and baby irgobot, that write data that spreads across, and between, points as well.
So having an extra basket after the "end of sgf" code into which a writer can put anything they want would keep everyone happy.
So i reckon the best way to extend sgf is to not extend sgf, but to extend the file containing sgf instead.