I think the categories should be kept fairly broad. If you define your projects, areas, and categories well, you shouldn't need too many categories. And some types of information fit better into a wiki rather than a case.
To go through your examples as I understand them (and my understanding of some of these is, admittedly, tenuous...):
Design (of a map or poster): presumably each poster or map (or set thereof) constitutes a project. I am still struggling to understand what sort of information would appear for this type of project (it's a long way out of my experience), but it seems to me that there are two types of cases related to it: information/data (about design, manufacturing processes, etc), and issues/problems. The information side of things might better appear in a related wiki rather than as a case, leaving issues/problems as "bugs," and allowing for the possibility of "inquiries." (Note that there is still a case to be made for having design, manufacturing, marketing, sales, and post sales as separate areas).
Data: I guess the deliverable here is one or more sets of related information, each of which is a project in its own right. I'm honestly still a little unclear here about what the benefit is to having a separate category for this. I see this as a class of project, which may have features, bugs, and enquiries against it, and a wiki as a repository for additional information, but the concept of a FogBugz category doesn't seem to apply directly.
Backbone: As db suggests, this sounds an awful lot like a project (or class of projects) rather than a category. It may make sense to have areas for backbone and sysadmin.
Support: Assuming this applies to each project, this seems to be covered by the Bug and Inquiry categories (again, possibly with a wiki for additional info) for the project. Why introduce a broader category to replace the two existing categories?
Research: I am not sure FogBugz is the correct tool for this, and without knowing exactly what the intended use is, I am probably going to embarass myself with my comments, but research involves formulating questions, determining how best to answer them, and answering them. One might conceivably have a Research category, with areas for, say, Thesis, Methodology, and Results for a given question (where each question might be a project?) but this feels a little awkward. This is another category of information which is probably better put in a wiki.
Sysadmin: see my comments for backbone.
