My understanding of tags is that they are global, not project-specific so I would think that the behavior you report is as expected (as long as the tags don't actually provide undue visibility to issues)

In our case, the problem was caught because product names from one private project leaked into another.

I could control this with a configuration flag. I would restrict tags to the current project if private, rather than being global.

The problem as I see it, is that the tag table does not contain a project_id field, so I'm not sure how you could differentiate a private / project-specific tag from a global one.

Maybe a feature request for a future release including a schema change ?

I was going to infer the project from the bugs the tags are attached to. Having a separate field is a simpler / faster idea.

Should this be 1.3 only then?

I was going to infer the project from the bugs the tags are attached to

Then how would you differentiate "global" tags from project-specific ones ?
It also doesn't sound very efficient from an SQL perspective

Should this be 1.3 only then?

I think it would be better, yes

Hava a look at the discussion at 0009716 and also the attached patch.