For private reasons affecting the reporting install, this no longer has customer impact.

The underlying problem here is that we select a default item from the list of configurations. However, each configuration may generate zero or more actual entries in the menu.

If it generates zero, we select an item which the viewer likely can't see.

If it generates more than one, this operation may not make much sense either.

We could:

1. Continue selecting a configuration, but give configurations a method like canViewerSeeThisThing($viewer), or just do this via PolicyInterface.
2. Instead of selecting a configuration, select a specific item.
3. Before selecting a configuration, generate its items and ignore configurations with zero items (this is basically (1) where the policy test is "does this generate any items?").
4. Rework the ability for configurations to generate 2+ items -- this capability may not really make sense.

I think we can probably make a better choice here later on.

In particular, if we don't need the capability in (4), removing it might be best. We don't currently use this capability, but if we want to add types of items which can generate several menu items (for example, "all children of wiki page X", or "links to all chatrooms with tag Y" or whatever -- any sort of thing where you configure one "item", and it dynamically produces a list of 2+ links in the actual menu at rendering time) we'd like to keep it. I suspect this capability will turn out to be useful sooner or later, and expanding it will probably lead to (or, at least, towards) a natural solution for this problem.