1. Cross-user weirdness

Binary lives in:
FVM_DIR="$HOME/.fvm_flutter" → e.g. /home/alice/.fvm_flutter/bin/fvm

Symlink lives in:
SYMLINK_TARGET="/usr/local/bin/fvm"

So:

User A installs FVM → /usr/local/bin/fvm -> /home/alice/.fvm_flutter/bin/fvm

User B runs fvm → executes code inside Alice’s home directory.

That’s bad for:

Security (one user’s home directory becomes part of another user’s runtime).

Correctness (if Alice deletes her home, B’s fvm breaks).

Principle of least surprise.

System-wide paths should not point into a specific user’s $HOME.

2. Permissions & sudo/doas friction

Right now a “normal user install” requires:

Write access to ~/.fvm_flutter ✅

Plus sudo/doas to touch /usr/local/bin ❌

So a non-privileged, per-user install still fails if:

No sudo/doas, or

/usr/local/bin is managed by something else (Nix, system packaging, etc.), or

You just don’t want the script messing with system dirs.

A per-user install ideally never needs privilege escalation.

3. Uninstall semantics are confusing

Uninstall runs as the current user and:

Deletes $HOME/.fvm_flutter

Removes /usr/local/bin/fvm (using sudo/doas)

But:

If multiple users are on the system and one uninstalls, they blow away a symlink that may have been created during a “system-ish” install.

If some admin later installs a global fvm to /usr/local/bin, your uninstall logic might remove it if the symlink target happens to match your heuristic.

4. Home directory dependence for a “system” binary

Even when you’re the only user:

/usr/local/bin/fvm depends on $HOME being the same directory used at install time.

If you move home, change username, or restore from backup with a different path → fvm is broken.

System binaries should not depend on the installer user’s $HOME.