The tag event API was changed to work around a limitation of how sticky events work. We need to be able to keep multiple sticky taglists on a pad without merging them or replacing all the earlier ones.

Reason, for example: a demuxer will typically extract "global" tags and send them in a separate taglist from per-stream tags. It is desirable to keep those separate to be able to tell which ones are in fact the global container tags and which are the per-stream tags.

Sources may produce tags (e.g. cd-text from audiocdsrc); tag parsers may produce tags (id3demux, apedemux, icydemux); containers may produce tags; decoders may produce tags (though this is now mostly left to containers or parsers); codec parsers may produce tags (e.g. bitrate updates - even if those are arguable not tags).

At the very least we need to make demuxers use different names for global container tags and per-stream tags, so both tags are maintained as sticky events on pads.

Ideally we would find a neat solution to integrate this with stream ids (see bug #634407 comment 25), but it was deemed too ambitious for this cycle. But if anyone has any ideas... (perhaps a path-like ID of the stream topology, something like filesrc0/matroskademux0/audio00 would do the trick, could easily be implemented via a recursive query).