I think this is something every DBA needs to know about, so thanks for sharing!
I have a small note though... I have restored master a few times on an instance on a VM on my laptop just to get some info about for example how a linked server was configured when someone thought it had changed. You are correct (of course you are :)) that the version needs to be exactly the same as the version where the backup was taken if you want to replace master.
However, I also wrote some code years ago to automatically verify backups. It selects a random instance and a random database, restores it (as dummydb), runs an integrity check, then mails us the result. Sometimes that random database happens to be master. The integrity check fails (internal tables and so) but the restore succeeds, on a different version. So I'm curious why that didn't work for you. To be sure, I tested it manually, restoring from 2014 and 2017 to 2019 (screen shots added - version numbers from/to are visible). Both succeeded. So the article you link to might no longer be valid. I do remember seeing that error message from your screen shot with the auto-restore checks as well, but I can't remember what exactly cause it or what I did to solve it (might have been an upgrade or edition change).
Screen shot successful restore from 2014 to 2019
Screen shot successful restore from 2017 to 2019
Maybe someone reading this came across this as well and has a better memory than me 🙂