Four possible approaches on this, although none are especially good:

• We plan to implement real subprojects eventually. This is the best fix, but might be the furthest away on the roadmap.
• We plan to implement "role profiles", which let you configure the default set of search filters for a group of users and possibly keep them up to date.
• We plan to implement dashboards and widgets, which might offer a few solutions.
• You could use Herald to enforce addition of superprojects.

In detail:

Subprojects: We plan to support real subprojects (T3670) but this isn't on the immediate roadmap and will probably be complicated. The task is pretty sparse on details. Some of the product questions have cleared up now (policies ended up mostly separated from projects) but there are a still a lot of edge cases. It's also not totally clear if this should be a strict tree (Project > Subproject) or we should just let you put projects in other projects (so a project like "iOS App Design" could be in both the "Mobile" and "Design" projects). With Tasks, we're leaning toward supporting both concepts (T4207) separately ("Dependencies" vs "Subtasks"), but currently support only dependencies.

Role Profiles: We plan to let you customize search filters, application tiles, and the homepage layout for different "Profiles", like "Customer Support Rep" vs "Engineer" (see T4103). Exactly how this will work is a bit fuzzy, but this might extend to letting you continue to update the defaults after putting a user in a given profile. But this gets messy with existing users (we don't want to overwrite their customizations) and is also generally messy and probably isn't getting built in the super near future (most of the interest in it seems to have died down a bit as installs have found reasonable workarounds). The motivating use case so far was more around onboarding new users than sharing queries.

Dashboards/Widgets: This is mostly in T3583. This is somewhat close to working, but I'm not exactly sure when it will get finished up and land or how much more work there is until we get somewhere we're happy with. It would let you replace the homepage with customizable widgets, and build your own custom dashboards. This might or might not have much overlap with what you're after, but at a minimum would probably let you create and maintain a widget which you could share, that would either issue or link to appropriate queries. But depending how this shakes out, it might just be one step better than having a wiki page where you maintain the most up-to date versions of queries.

Herald: This is kind of funky and brute-forcey, but you can write a Herald rule like:

When:
  [ Projects ][ include any of ][ subproject1, subproject2 ]
Take actions:
  [ Add project ][ superproject ]

This would solve the human issue, but you'd have to write one of these rules for every superproject. On the bright side, you can do this today.

The cleanest fix by far here is for us to just come up with a more concrete subproject plan and implement it. I think that will happen in the next 6-ish months, but it's hard to commit to a higher prioritization than that. The plans are still pretty fuzzy.

In your case, do all your subprojects unambiguously belong to exactly one superproject, or do you have cases like "iOS App Design" belonging to both "Mobile" and "Design"? And are your subprojects 2 levels deep, or more-than-two levels deep?

I'm going to merge this into T3670 since I think that's the ultimate solution after talking with @ahoffer2, but let us know if you have other questions.