Probly related to this "--prefix" line

      extraWrapperArgs = builtins.concatStringsSep " " (
        (optional (
          config.extraPackages != [ ]
        ) ''--prefix PATH : "${lib.makeBinPath config.extraPackages}"'')
        ++ (optional config.wrapRc ''--add-flags -u --add-flags "${initFile}"'')
      );

I think this is effectively a duplicate of #2893.

Note that neither --suffix or --prefix are “better” for adding to the PATH, rather it is situational and/or subjective which to use.

Nixvim abruptly switching from prefix to suffix would be a potentially disruptive breaking change, as many users will be expecting the executables installed by nixvim to take priority in vim's PATH.

In general, allowing the impure environment to take priority on the PATH sounds like a bad idea, although for LSPs it is often what is desired.

Up until now, we have advised setting the relevant package option to null when you want to use the impure executable from the environment's PATH. However I can see a use case for specific packages to be installed as fallbacks.

I think we need to do a bit of head scratching, and come up with a way to define both overrides (prefix) and fallbacks (suffix).

I think adding an attribute to indicate prefix/suffix makes sense for this code base, almost every maintainers put it highly on "backward compatibility", nobody wants be flooded by complaints.

It's quite alike #2893, but this is for the LSPs, maybe a future PR can closes these two.

In general, allowing the impure environment to take priority on the PATH sounds like a bad idea, although for LSPs it is often what is desired.

It does not sound like a bad idea to me, that exactly what I want.