You may be aware of this already, but the current LiveView generators address many of these concerns by serving the same LiveView template for multiple routes, but the assigns will be different based on which route is accessed. So, for the :index route, the modal will not be visible, but it will be visible for the :new route. Plus, with live patching, you preserve back button functionality (and it even preserves the page state as a bonus). So that addresses the back button problem.
But the problem still exists where clicking outside the modal (or pressing the back button) will destroy the form and any unmodified content, which is super annoying. This can be addressed by listening for changes to the form's input fields and showing a warning when any navigation event occurs when the form is changed-but-not-submitted (easier said than done, but ).
I'm not even disagreeing with your point, really. It's just worth mentioning that 1) many of the problems described have an out-of-the-box solution when using the current LiveView generators, and 2) refinements can be made to address some of the remaining issues.
Yes, "it depends". If you're building something internal and Desktop-only then maybe a Modal can be OK. But for a mobile-first app, you will never be able to test it on all the devices people use so consistent UI/UX is impossible.
If you have ever done any "in the wild" usability testing with older people with older devices (think iPhone 8 form factor) Modals often break the UX. Seen it happen many times, it's super frustrating to the person trying to use it. :-(
I don't think modals are very usable for forms, especially if the form is big – it risks somebody spending a lot of time filling out the form and then closing the modal by accident. I would much prefer a `/resource/[new|edit]`
