> A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task.

That cherry on top can be just as easily implemented by opening the /login in a new tab. Auth gets set, there, user is logged in even in the old tab, and doesn't lose his position in the page either.

Added cherry on top of that: If the user decides to log into the page halfway through the application, he can still bookmark the login page.

The same is true for almost every other use case of a modal where it displays a resource.

Tabs are builtin capabilities of the browser. Even terminal browsers like w3m support tabs. Why built something else that can be built poorly, instead of using what the browser already can do?

> these sound like issues with poorly done modals.

There is no other kind. The whole idea of modal window is stupid. It constrains the user instead of empowering them.

Solve the server's problems some other way that doesn't impact the user.

These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead.

> One key design principle of modals is to make them mentally cheap to open/close/reopen

Cheap for whom?

> URLs are routed to modals

In this current age, this usually means an SPA that will first load the underlying page, then the entire application bundle, start up the JS, detect the route, load the data for the modal over another request, and finally display the modal. In the multiple seconds this is happening, nothing indicates that a modal will be opened. Sounds familiar?