Use the following sample data:
Project A: has Cat1, Cat2, Cat3
Project B: has Cat2, Cat7, Cat10

Following are the three approaches, which approach to follow maybe be controlled by a configuration option:

1. Same as now.
2. Show all unique categories (Cat1, Cat2, Cat3, Cat7, Cat10)
3. Show all categories ([Project A] Cat1, [Project A] Cat2, [Project A] Cat3, [Project B] Cat2, [Project B] Cat7, [Project B] Cat10).

Option 1 and 2 seem to be the easiest and make sense to me. I think opertion 3 will affect the filtering code and will be redundant with respect to filtering by category within a specific project.

1.1.0 uses Option 2 and this seems very satisfactory. If someone wants to achieve Option 3 they can easily make the category names unique.

I think this can be closed.

For filtering, the current behavior is like option 2, in that categories with the same name are lumped together. When global categories are implemented, I will evaluate possible ways to mark a distinction between global and project categories, but the overall functionality will likely stay the same.

However, when selecting categories for new/existing issues (ie. not filtering), there will be definite distinctions between categories for each project, parent projects, global categories, etc.

Once the patches from bug 0008435 make it into trunk, this will be taken care of.