Need to set `rangeFormatting` option twice in order for range formatting to work (in neovim)

(Cross-posting here from https://users.rust-lang.org/t/need-to-set-rangeformatting-option-twice-in-order-for-range-formatting-to-work-using-rust-analyzer-in-neovim/111978/1 because this might be a bit too specialized for the rust forum)

For context: I am currently learning about LSPs, because I am migrating from a VSCode to a NeoVim setup. I am working in an old codebase, where I need to get range formatting set up, since I often need to change small parts of legacy files without polluting diffs. Range formatting used to work for me in VSCode, but now that I am switching editors, I had a hard time turning the documentRangeFormatting capability on rust-analyzer on in NVim, and having it actually carry out the range formatting.

Initially, my entire rust-analyzer config was sent through the workspace/didChangeConfiguration LSP Call (with the config in the initialize call being empty), but this failed to activate the documentRangeFormattingProvider capability when the LSP came up. (NOTE: I did not manually do this, a neovim plugin called lspconfig did this for me, but this is what I observed in the logs).

I made some changes to have the relevant rustfmt.rangeFormatting.enable = true option sent as part of the initialize LSP request instead, and lo and behold, the LSP came up with documentRangeFormattingProvider enabled! However, range formatting still did not work, as I got the following well-known error message:

[DEBUG][2024-05-25 19:45:52] .../vim/lsp/rpc.lua:408	"rpc.receive"	{  error = {    code = -32600,    message = "rustfmt range formatting is unstable. Opt-in by using a nightly build of rustfmt and setting `rustfmt.rangeFormatting.enable` to true in your LSP configuration"  },  id = 12,  jsonrpc = "2.0"}

I hence set up my NVim plugin to send rustfmt.rangeFormatting.enable both during init and when changing the configuration, and this worked! However, this makes me wonder if I should be moving some of my other settings to init-time rather than config change time, and whether this somewhat strange duplicated workflow is a well-known issue. On a likely unrelated note, I am not receiving diagnostics inside test modules gated by #[cfg(test)], but have not set allTargets to false...

Reproduce the setup described with NeoVim, lspconfig, and rust-analyzer, comparing rustfmt.rangeFormatting.enable sent during initialize with workspace/didChangeConfiguration. Inspect the LSP logs and the range-formatting response to determine whether both configuration paths are required. Done means the configuration behavior and any impact on test-module diagnostics are documented or covered by an appropriate regression test.