Even if it is announced what is going to be changed that won't solve much.
SE would first need a list of used user scripts that use certain elements as their hook/extension point. Then they would need to evaluate if a change would impact user scripts that use that element. If yes, they would announce the change and for it to be useful it would need to include how that element would change (size, position, and removed).
You need a working implementation before you can determine if a user script is impacted by a change. Then the user script author needs time to make the needed changes, test them and make them ready to work with the changes.
In theory you could open https://dev.stackoverflow.com for this. And SE could create public extension points for their software. That still doesn't guarantee that userscripts won't break. For example, for those scripts that the maintainer is no longer interested in maintaining.
Keep in mind that SE pushes changes out daily. It would cripple their progress if they have to include external script developers into their stakeholder mix.
The current system works fine. Users find a bug, create an actionable bug report, ping the maintainer and they fix it. In case of major rework some chat rooms might have to facilitate in pinning a message to their starboard to prevent that the user script developer is more occupied with replying with yes, I know there is an issue, I'm fixing it then with actually fixing the bug.
I want SE developers to make progress. We have plenty of resources and users that are capable of adapting after a breaking change has been pushed to production.