Hi @JasonElkin and @warren
Thanks for highlighting this.
I agree that it would be ideal if Opening a Dialog did not close by any URL activity happening of that same event. (I would still prefer any later navigation to close it, like if the user navigating backwards with the browser history).
So Jason your hack might be the right solution, but we would have to investigate this further to make sure it covers scenarios of deep URLs based on Extensions that has to be loaded and Extension that uses the Condition system.
Now I do something bad, but I hope you can manage, a question for each of you:
On the broader conceptual level I would really love if you, @JasonElkin, could describe your use-case, from a User Experience perspective.
I would love to get an understanding of the case where a dialog appearing not by the users immediate interaction is the right solution from a User Experience perspective.
For Warrens case here above I have to be honest and say that I do not think using a Dialog for this case is ideal. The dialog comes a long aggressive as it enforces the user to respond to it — Something the user did not specifically ask for.
To highlight my case, imagine the user strolling around to find a specific Document, so they click through documents of the tree. Suddenly, they hit a ´locked´ document and now they are prevented from navigating away from the document, but they have to respond to the dialog first.
Instead, I would suggest making something that only fills the visual space of the Workspace. Still enabling the user to navigate the Tree(Sidebar) and the Topbar(Sections, Header-apps)
Something less like a Dialog, but more like a Lock-layer that dims the Workspace. Imagine a sci-fi shield in front of the Workspace.
In this way you could also make your Action of it, more relevant. Instead of Close it could be View in read-only mode or Enforce access or what ever makes sense in terms of this specific feature you are building. 
Let me know what you think @warren