The solution you have come up with is the same one I did a while back. One recommendation that I have for you, in order to ease upgradeability, is to create a package for your site named something like packages/mysite and put your new proc a /packages/mysite/tcl/mysite-customized-procs-init.tcl file, which would reference where the original procs are from and what you customized via a comment that is something like:
# From acs-templating/tcl/list-procs.tcl
# changed return make csv download as an
# attachment
ad_proc -public template::list::write_output {
...
This file would contain all procs you customize for your site. That way when you do an upgrade to a new version of acs-templating your customized proc would remain active. Packages are sourced alphabetically first with the -procs files then the -init files. Your custom proc will be initialized after all the procs files load since its an init file thus upgrading won't override your customized procs.
I used to document changes that I needed to make to a bunch of packages and every upgrade was a hassel since I had to redo all my changes - which got trickier and tricker the more i customized. Now, when I upgrade, I simply look in my /packages/mysite/tcl/mysite-customized-procs-init.tcl file and compare those procs to the ones that are in the upgraded packages. If there are differences, especially security changes, between the new ones and the procs I customized off of I choose what and how to modify my custom proc to match the changes made by the upgrade and my sites custom needs. Most of the procs I customized aren't changed with every upgrade so I don't have to do any customizations to those procs to keep running the way my users expect it to.
I hope this helps.
