This is not something that should be handled in a blanket, black-and-white, "general principle" manner. It's fine to agree that:
- "Lots of different functions represent [generally] the same behavior or goal..." and
- "It would make no sense to have different tags for the same topic" and
- "We should tag by behavior"
I agree with all of that.
However, there are functions and there are functions. And behaviors and behaviors. And a function implies/represents a behavior. It's not about one vs the other - especially for a language like Lisp and an extensible environment like Emacs.
Both (some) function names and (some) behavioral categories can make sense as tags. We are not just erecting a lattice of theoretical categories when we define a set of tags. We are trying to help users search. What terms will Emacs-site users think in? should be a question that informs what tags we end up with.
The idea should not be to replace useful, Emacs-specific keywords that represent important and well known behaviors with super-general, overly abstract "behavior" categories that people will not search on or that will not prove useful in practice if searched on because they are so general.
Consider the tags syntax-highlighting and font-lock on Stack Overflow. Both exist. The latter is pretty much specific to Emacs. But someone might argue that the former is more abstract and more "behavior"-oriented, and so should subsume the latter. Fortunately (IMO), SO has allowed both. They are both useful, even though, yes, there is overlap.
Here is a case in point of what I think is misguided. Emacs "functions" autoload and require have specific meanings and are terms that users will use to narrow searches. These are not like fill-paragraph and fill-region. (And I agree that a fill or filling or text-filling tag is generally more useful than those individual fill-* function names.)
Replacing the rich, meaningful, specific, well known, and easily confused terms autoload and require with the general tag libraries is misguided here, IMO. Users are more likely to search using the former than the latter. I am not against having, and using, a tag libraries - I am even in favor of its addition to that question. I am against systematically removing tags such as autoload and require in favor of the more general, more "behavioral" tag libraries.
In the end, this kind of thing requires judgment. And it is ultimately about what is most practical for search by users of the site. It's not only about finding high-level, abstract categories that form a nice hierarchy or that partition the search space. It's about having tags that reflect what users will use for searching.
Beyond this gripe, I find it a bit unfortunate that we are already, a week or two into Beta, editing away the tags that users apply to their questions. Some time and experience should help determine which tags are most useful - whether, for instance we should have filling, text-filling, or both. For now, at least, we should err on the side of giving users the benefit of the doubt when they apply and invent tags.
If a user wants to tag a question unwind-protect, allow it. We gain nothing by removing such a tag or replacing it with some watered-down term that applies more broadly. Yes, sure, we can have a general tag such as non-local-exits (the general term that the Elisp manual uses where it describes unwind-protect). But we can allow unwind-protect too. Why? Because it will be useful to people searching this site.
It's a bit early for the Tag Police to be making the rounds, applying and citing "general principles" such as the one proposed in this post. As for that principle: it's fine as far as it goes, but (a) a particular function name is sometimes the best name to represent a behavior, and (b) application of such a "rule" requires judgment. It should not be about memorizing a catechism and applying it indiscriminately.