Given my last comment it would be "covered"/"used" as the latest fallback so I would not use it here (inverting the condition and use the legacy only if present)

I don't understand. "home" here is just a fallback in case anything goes wrong with the detection?

... a more proper way would be to use os.Getwd() I guess

my point is that we have to handle a global fallback case if everything fails.
this is the . case.
because we will handle it as a last resort anyway, we don't have to deal with it here, which allows for early returns without variables leaking or inaccurate naming (the naming is inaccurate in the last return legacy in the sense it is a fallback not necessarily a legacy path). eg, something as:

// use the old path if it exists already
if home, err := os.UserHomeDir(); err != nil {
	legacyPath := filepath.Join(home, "."+confDir)
        if _, err := os.Stat(legacyPath); !os.IsNotExist(err) {
		return legacyPath
	}
}

I see, thanks for the explanation. "home" at this point was the base for the following legacy folder check and also the check for a macos ~/.config. I guess if we remove the macos stuff this can go too.

If we include this like your proposal though, legacyPath will be needed again in the last return.

this check is not strict enough and might make the $HOME/.config directory be used without the user "consent". If an application creates a directory at any point, the CLI will start to use the previous directory without the user knowing it.

That is true, and it already crossed my mind. As we have no way to keep track of the last used path (and also it would be out of scope here), I removed this check.