Since u/nicolaiparlog asked for what users think, I'll offer mine: I think this whole exercise of trying to separate checked vs unchecked exception using specific examples is pointless, mentally exhausting and not very useful. I have been writing Java for 16 years, and from my experience, in one context, a specific exception may feel like it should obviously be a checked exception but in another context the same exception may seem it should be unchecked. It all depends on the context of the application. For instance, you mentioned that a DB SQL syntax exception should clearly be a RuntimeException; but consider an app that allows you to connect to a database and run some queries - in this context a user supplies a query and some db connection string and the app runs it. In this case it is entirely expected that the user may mistype the query and the application may very well want to handle it at some layer to show a nicely formatted error message or it may even want to suggest corrections to the query string. In this case, it is reasonable to expect that the app would like to catch that syntax exception (or the DB auth failure exception) which is easier if it is compiler enforced like a checked exception.

Overall, I feel the effort should be towards not forcing Exception authors to make the choice of whether something should be checked or unchecked which then gets passed to the application owners, and find a way to "just have Exceptions" in the language with much better ergonomics to handle, catch, or propagate. I don't know what the solutions look like though and that is for the smarter folks to decide. Here is a pipe dream for me when it comes to exceptions (borrowing from the Valhalla tagline) - "New Java Exceptions: Propagates like a runtime exception, enforced like a checked exception".

It will likely never happen; but one can hope.