What would be the result of losing these providerLuaRc variables for a downstream consumer of the wrapper?

Before:

exec "/nix/store/wr7j2629j0hmipa1mb966xagk174q5ky-neovim-byte-compiled-0.11.6/bin/nvim"  --cmd "lua
vim.g.loaded_node_provider=0;vim.g.loaded_perl_provider=0;vim.g.loaded_python_provider=0;vim.g.python3_host_prog='/nix/store/c4bfr9cl8nmlggzjg40q3z5pvalpgpkz-neovim-0.11.6/bin/nvim-python3';vim.g.ruby_host_prog='/nix/store/c4bfr9cl8nmlggzjg40q3z5pvalpgpkz-neovim-0.11.6/bin/nvim-ruby'" --cmd "set packpath^=/nix/store/q8cjdv0idypwjypmai84mg4g1pymws3a-vim-pack-dir" --cmd "set rtp^=/nix/store/q8cjdv0idypwjypmai84mg4g1pymws3a-vim-pack-dir" -u
/nix/store/g8d7m5y1alrh0w71phig6kyah9q2b66v-init.lua "$@"

After:

exec "/nix/store/wr7j2629j0hmipa1mb966xagk174q5ky-neovim-byte-compiled-0.11.6/bin/nvim"  --cmd "set packpath^=/nix/store/xssf72bmwy0pqhb8sk4rz3djs4nww7rp-vim-pack-dir" --cmd "set
rtp^=/nix/store/xssf72bmwy0pqhb8sk4rz3djs4nww7rp-vim-pack-dir" -u /nix/store/86sl0w2kp7f6hm6vqhhpqb75gvy5lfhn-init.lua "$@"

Is this just going to make Neovim search for those on PATH instead of automatically including the direct paths?

nope the same code is included in the generated rcContent instead https://github.com/NixOS/nixpkgs/pull/487390/changes#diff-647e8d1c5843195e278d71753f17d2183d961166104c8c55edc4cb93768579ddR108

i.e a plain user should not see the difference, someone setting wrapRc = false will be fine if he already includes the wrapper luaRcContent somehow. If he doesn't, now he must :p

I guess what I was trying to figure out was, this is technically a breaking change that generates a different wrapper for those relying on it from there. What is the effect of that no longer being included in the wrapper and / or recommended migration for consumers of the existing wrapper semantics?

Should probably have a short blurb in release notes about the behavior changing so there's something to reference if a config stops working how it had before the change.

Just trying to avoid surprising people with undocumented changes if they will affect neovim at runtime.

Maybe i'm being overly cautious @mrcjkb any thoughts?

Before this PR, the neovim wrapper was invoked with

nvim --cmd ":lua ${providerLuaRc}" "$@"

--cmd flags are invoked after init.lua (you can test this by adding vim.g.foo = "hello" to your init.lua and then running nvim --cmd ":lua vim.print(vim.g.foo or 'foo unset')").

So this PR moves the sourcing of the providerLuaRc to an earlier point of Neovim's startup sequence.

Technically, a config could break if it tries to use one of the providers in the init.lua and the user doesn't know that they have it disabled.
I think it's highly unlikely, as providers are typically used by plugins and Neovim loads providers lazily using :h autoload scripts.
For example, the python provider is only loaded if a user or a plugin calls the Vimscript function provider#python3#Call or provider#python3#Require.

If anything setting the providers earlier could fix things where a plugin checks if the provider is set (and currently thinks it's not). I doubt many users use remote plugins. With the remark of marc, I've updated the commit description to :

1. mention who might be concerned ( which I think is really a small number)
2. how to fix that in those degenerate cases