Usually, "bzr merge" can be thought of as an exploratory command. If you "bzr merge ../other" and don't like the result, you can "bzr revert", and there are effectively no changes to your branch (committed information). People who branch from you won't see the revisions (since we only copy ancestry), etc.
However, if the merge source includes any tags, those tags will be applied to your local Branch (such that they propagate to 3rd parties), without any sort of confirmation. Further, commands like "bzr revert" won't remove them from your Branch.
'bzr merge; bzr revert' also has the odd side effect that it can cause your Branch to start propagating a tag pointing to a revision which you don't have. If Joe merges Sue and reverts her change, he has her tag, but also her revision. However if he pushes his changes to Dave, he will propagate Sue's tag, without propagating Sue's revision.
It made more sense when tags were a "repository" property, but now that they are a "Branch" property, we may need them to also exist only in the working tree until a commit is made... (Maybe).
As an example:
radix@haruko ~/test% mkdir a
radix@haruko ~/test% cd a
radix@haruko ~/test/a% bzr init
radix@haruko ~/test/a% bzr commit --unchanged -m 'first rev'
Committed revision 1.
radix@haruko ~/test/a% cd ..
radix@haruko ~/test% bzr branch a b
Branched 1 revision(s).
radix@haruko ~/test% cd a
radix@haruko ~/test/a% bzr tags
radix@haruko ~/test/a% cd ../b
radix@haruko ~/test/b% bzr tags
radix@haruko ~/test/b% cd ../a
radix@haruko ~/test/a% bzr tag what
Created tag what.
radix@haruko ~/test/a% bzr commit --unchanged -m 'second rev'
Committed revision 2.
radix@haruko ~/test/a% cd ../b
radix@haruko ~/test/b% bzr merge ../a
All changes applied successfully.
radix@haruko ~/test/b% bzr st
pending merges:
Christopher Armst... 2007-03-30 second rev
radix@haruko ~/test/b% bzr tags
what <email address hidden>
radix@haruko ~/test/b% bzr revert
radix@haruko ~/test/b% bzr st
radix@haruko ~/test/b% bzr tags
what <email address hidden>
I posit that 'what' should gone after that revert.
Why?
Tags not a working tree operation. So 'revert' has no effect on them.
The local repository still has a copy of '<email address hidden>', so you could do
bzr merge -r revid:<email address hidden>
or equivalently
bzr merge -r tag:what
Supporting this would be tricky at best, because there are other ways to get tags. You can create a tag on an old revision (for example).
So if I tag revision -10 as "release-1.0". Which you already have (but I forgot to tag when I released).
And then you merge my tip because I've done more work. Do you want to not get that tag? Should "bzr revert" still remove the new tag (even though it is a tag on a revision in your current history)
If this is important to you, the best I can come up with is having merge track what tags are added (in a custom file) and then if you do "bzr revert" it will run "bzr tag --delete" for you.