The problem with blacklisting is that you're introducing unexpected behaviour at a distance in contexts which are likely to silently pass through the result without compile-time errors.
(I was lucky that my
justfile was calling commands that produced error messages when the Just variables were replaced with nothing. Things like Django/Jinja/Twig/etc.-style HTML templates would just silently do the wrong thing.)
Also, substituting templating variables is typically only going to be done for one or a few files.
It makes much more sense to whitelist, rather than blacklist, both for reasons of intuitiveness (you get verbatim behaviour unless you ask for templating and you've got a clear, exact list of files which this behaviour will be applied to) and convenience (you don't have to amend the blacklist every time you add a new HTML template to your project).
While it'd be nice to have the option of a place to keep templates that is out of the way, I keep mine in
~/src/ alongside my projects so all of my backup configuration and navigational shell shortcutting just work. I wouldn't want to be forced to use a
~/.templates to get compact "init a new project" commands. (Also, you're not supposed to create new dotfiles/dotdirs directly in
...though, worst case, I suppose I could
ln -s src ~/.templates
Be aware that I'm not that atypical as programmers go and that in itself would probably be enough to prompt me to just bundle my homegrown templating solution with every project template I publish to avoid having to deal with two separate templating solutions for the same language.
(It's not as if I'm getting paid to write these things, so I might as well optimize for my own convenience.)