Hi @BogdanZavu, thank you for addressing the comments.
I wanted to clarify what I stated above a bit.

There are times we do break the API and document it like you originally had done. But this should only be done when theres no good alternative solution that does not break the API - or there is good enough reason to intentionally break an API.

For example - we broke (and probably will again) the Helix 3d graphics APIs within a minor release:

• external types had leaked in the public Dynamo API.
• use was very low.
• most importantly, the experience for regular dynamo users was severely degraded in the older version of helix, and updating meant they no longer needed to install directX10.

In general I think principles like this should be used to judge API breaks.

• What API is being broken/what is the benefit?
• how many users will it effect negatively, how many positively?
• can we do it some other way and keep both apis working for a bit longer?
• Is the API popular? Is it an API we actively advertise (extensions) or just something that is public because of historical reasons.(helix)

I was thinking of this more as a fix rather than an API change. Whoever subscribes to the clearing event most likely will get the workspace from somewhere else.