Hello,
In general, it's not the role of LSP4E to "type" the projects (ie add nature). LSP4E works perfectly without natures, and adding a requirement on a nature would drastically increase the usage complexity and the maintenance code. It's basically not desirable for LSP4E to rely on project natures when just using file locations (as it does now) brings much more usability (support for files outside of workspace or in any kind of projects) without extra effort.
In case some specific project need some specific nature, it's the duty of the LSP4E "consumer" to ship the necessary code in their plugin to define the nature and use it.
In this case, the Metals plugin is where support for a Metals nature and some Bloop actions should be developed, as they're not at all related with LSP4E, but more to other project management features.
Now, independently of LSP4E, I'd like to raise a question: why even typing projects statically with natures? Which features of it do you want to bring for your use-case? In Wild Web Developer, we've rejected the idea of natures, and by using "dynamic" check (existing marker file, or file extension or whatever...) we can have the right action available at the right place, and the result is much easier to use than forcing users to go through specific wizards to enable some features on the code they import.
