codeAction and codeLens are valuable generic hooks for the server to provide features. These features are limited by what actions LSP allows the server to trigger on the client.

Today the most useful are: applyTextEdits, showMessage, showDocument (new, thanks!). It'd be a nice addition to be able to publish a list of locations, similar to how textDocument/references results are displayed.

The most obvious use case: "show references" is the stock example of a code lens, but can't be implemented directly in LSP today. (It requires some extension like a known Command name that is handled by an editor plugin). #788 suggests to standardize some such Commands, but a server->client request would be more composable, easier to document, be guarded by capabilities in a better-understood way, etc.

(clangd is considering implementing this as an extension as part of our codeLens support, in order to clearly document what client support is required)

My 2p FWIW.

1. Experience has shown that: server vendors won't document it, and they will only implement client glue for vscode. These sorts of assumptions make it impossible to write "generic" clients which don't have per-server code. This is essential for smaller project that don't have the scale to write code for every possible LSP server (there are many examples of this type of client)

2/3. that seems doable. I.e. server can request that client makes a particular type of existing LSP request. i think I prefer the way 3 is defined personally, as the whole mechanism of 'commands' isn't truly general and assumes particular type of client implementation, whereas 3 only uses existing high level protocol concepts (admittedly, commands are part of the protocol, though they're kind of nuts-and-bolts requiring a lot of client-side knowledge of servers)