Either adding your script directory in front of the PATH, or creating `alias` that provide a full path to your script where a conflict exists, makes a whole lot more sense to me.

I've never had this collision problem yet, despite appending my script directory to the end, but I'll use either of the above solutions if that ever becomes a problem.

From my own aliases:

   alias curl='/opt/homebrew/opt/curl/bin/curl '
   alias rsync-copy='/opt/homebrew/bin/rsync -avz --progress -h '
   alias rsync-move='/opt/homebrew/bin/rsync -avz --progress -h --remove-source-files '
   alias rsync-synchronize='/opt/homebrew/bin/rsync -avzu --delete --progress -h '
   alias rsync-update='/opt/homebrew/bin/rsync -avzu --progress -h '
   alias vi='/opt/homebrew/bin/vim -S ~/.vimrc'
   alias vim='/opt/homebrew/bin/vim -S ~/.vimrc'
   alias wget='/opt/homebrew/bin/wget -c '

One rarely actually needs to shadow binaries. Some cases could indeed be covered by introducing an alias that binds the binary's name to call a different copy of that binary.

You use shadowing to fix issues where you install some software that expects you to have a sane and ~recent version of some tool like git, but you don't as your system provides that binary and unfortunately it is either not sane (not GENERALLY sane [while it could be sane for system scripts]) or not recent enough. In that case the program's function would simply fail if it would call the system's binary and you shadow the binary with your version to fix that.

> adding your script directory in front of the PATH

That's a poor advice for the scripts you call relatively frequently. Instead, (as a general approach, we aren't discussing some particular script) don't use shadowing for scripts: just pick a non-conflicting script name and append the script's dir to $PATH.