Since I haven't used ref tags before, I don't understand how prepending ref makes it clearer what the tag represents. For example, I don't know what ref:linz:building_id or ref:GB:uprn represent. My first instinct would be to search the OSM wiki, but having the "ref" prefix doesn't make its representation any clearer.
I'm generally in agreement that more verbose, namespaced tags will prevent name collision, but this goes against the feedback I was provided in the local-vermont slack group, so perhaps I can go back to them to "buy-in".
My take away is that, practically speaking, it makes the most sense for a tag to have its own Wiki page, and if a tag is already in use (assuming it isn't super generic), that an alternative unique tag be used and documented instead. That seems like a convention that, for better or worse, is already in place.

Let me know if you have additional details about how ref is used like this, or how it would be beneficial, as I'm unfamiliar with its usage. I didn't find much beyond the wiki page <ref=*> The description and examples do not match what I'm trying to do.
I'm following the convention that I first came across with the New York state address point import with a syntax of:
source:dataset-name:field-name=value
It is intended for future automation, or semi-automatic change tracking, and gives a clear view of where the ID value originates from.
My original values were more verbose, with the intention of making it clearer to people that happen to come across it, but the feedback from the Vermont OSM community was to shorten it, and document it on the Vermont OSM wiki page. Thanks.

Hi mueschel. Thanks for your comment. This tag is designed to provide a connection to a dataset that is maintained by the Vermont Center for Geographic Information. My hope is to use this key to track changes and additions to the dataset, and update OSM accordingly.
At this point, I consider it experimental. I'm testing this out now by adding the tag to Solar farms in Vermont. If it proves useful, I will propose the expansion of its use within the Vermont mapping community.
I've previously brought this up on the local-vermont Slack channel. To prevent any additional questions or confusion, I've also just now added a note to the Vermont OSM wiki page.
This is my first time using such a tag, so if you have other suggestions of how to properly document it, please let me know.
Thanks.

I took a look at the changeset.

It looks like the building that no longer exists is 2651 Academy Rd. Thanks for catching this. It does still show up in the Esri World Imagery (Clarity) background.

It looks like 2682 Academy Rd may have already had an address added to the building footprint. So I should not have added the address point/node from the National Address Database.

It doesn't look to me that any of the other addresses existed before I added them. I added this batch as nodes and placed them over the building location (sometimes with an existing building footprint, sometimes no footprint). It is my understanding that adding addresses as nodes that are over a building footprint is a common and accepted method. (In cases where the building only has one address, it also okay to conflate them into one (the address is part of the footprint/way, but it is an extra step that I'm thinking I may be able to automate at a later stage.)

I'm not sure what tool you used to combine the address with the building way, but it looks like it made the address part of one of the nodes in the building way. I haven't seen this method before. I'm not sure if it is accepted or common, but it seems "cleaner" to make the address tags part of the way (whole footprint) rather than a single node.

The way I combine them is in the ID editor, I select both the building footprint and the address point (shift-click to get both selected). Then I type the "c" shortcut and that combines them together.

For consistency, I'd suggest we do this with the addresses in this changeset.

Let me know if I missed anything, or you have any questions.

Thanks again for your help with mapping VT. Jared

Hi A Hall! Thanks for raising your concern and glad to know of another mapper in the Upper Valley.

I've been adding addresses around VT. So far, everything has been manual in batches of ~50 using the RapID editor. As ezekielf mentioned, I use whatever seems like the newest aerial imagery available, but those are definitely sometimes years old.
I've also been trying to conflate (combine) address points that I'm adding with building footprints. In my experience, it usually does a decent job of adding whatever is missing. But the interface doesn't always make it super clear, so I may have made an error. I'll try to have a closer look at the changeset, but if you can provide any specific examples, I'd like to check them out so I don't make the mistake elsewhere.
Thanks again. jared