My tentative plan here is:

• Turn PhabricatorUserPreferences into a full object which implements PhabricatorApplicationTransactionInterface.
• Rebuild /settings/ in a parallel /settings-pro/ using EditEngine + transactions + modular settings + modular groups (these are partially modular already?), making sure each setting has an option to set it to "default".
• Support the creation of standalone preferences sets which are not bound to a particular user.
• Wire up the inheritance stuff, caching, global assignment, etc., to make this actually work.

This is mostly straightforward. A few controls have some level of issue:

• Translation: I want to separate "complete", "usable", "very incomplete", and "special (silly/developer)" translations in this menu, but that's just an <optgroup /> sort of thing. Some adjacency to T5267.
• Pronoun: Not sure if setting a global default is useful here, although I could perhaps imagine, say, a summer program for female engineering students might want to default the pronoun to "her". Feels a little weird to have an explicit "Use Server Default" option here though, so I'll likely keep the visible behavior the same even if I do make it possible to specify a default pronoun.
• Timezone: needs explicit "use default". Grouping by GMT offset might be helpful.
• Time of day: needs explicit "use default".
• Date format: needs explicit "use default".
• Week starts on: needs explicit "use default".
• Conpherence preferences: needs explicit "use default" and also this panel is silly, but probably a battle for another day.
• Desktop notifications: needs explicit "use default". This panel has some magic.
• Diff preferences: 3x defaults.
• Display preferences: 4x defaults. Need a way to enter both "use default" and "empty string" in a textarea? Maybe it's fine to not be able to set these to empty string if the server specifies a default. These seem to be the only textarea prefs we have, so probably fine to cheat.
• Home page: Needs complex weirdness if we're going to try to merge the defaults with user settings, or nothing if we're just going to overwrite. Maybe needs "reset to default"? Maybe also needs "show default" if it has "reset to default"?
• Search preferences: These options are so, so, so dumb.
  • I'm going to remove the jump nav setting. I don't think there's any reason to ever disable it, and it came from an abundance of caution ages ago in T916.
  • I'm going to remove the "/" setting and the "/"-to-focus behavior. See T916 + T989. T989 is a compelling reason not to support this behavior. Users can add this behavior with browser extensions or we can pick some legitimately unused keystroke if there is somehow outcry about removing this. At least in my browser, the "tab" key has the same effect and is more obvious.
• Developer settings / Dark Console: this doesn't really need a default but I guess. This option is also kind of weird.
• Email Format: Already have defaults.
• Email Preferences: 2x defaults, and then I guess we just add "use server default" to the 400 notification options. ¯\_(ツ)_/¯ This needs fixing but here is probably not the time or place.

None of the other stuff is "real" settings that make any sense to inherit.

There are some additional things stored in settings that have no corresponding preference panel (like the collapsed state of the durable column, and of the filetree browser, and ignored timezone offsets) but these don't make sense to set as defaults.

Summarizing caching for my own benefit. See also T10078, T10077.

Availability Cache: On-object. Maybe move to user cache. Uses weird NO_MUTATE.

Profile Image Cache: On-object. Maybe move to user cache. Uses weird NO_MUTATE.

Preferences: Not cached. Create and move to user cache.

• Dirty user record on any user-attached preference write.
• Dirty all user records on any any global preference write.
• Version internally so we can nuke this cache without migrations later?

Notification Count: Not cached. User cache?

• Dirty user record on notification clear.
• Dirty user record on any publish.
• Why does this load twice?

Conpherence Count: Not cached. User cache?

• When does this thing dirty?
• Why does this load twice?

EditEngine + "Quick Create Menu" (T10077)

• Huge huge mess.
• Hard to store; hard to dirty.
• Dirty all on any config edit?
• Dirty user on on policy error?
• Probably good enough.

Global Search Settings: Not cached. User cache?

• Sort of tricky to reduce to a cacheable value?
• Dirty cache on save of named queries.

Mystery Query: Where is this coming from?

• SELECT `user`.* FROM `user` user WHERE (user.phid IN ('PHID-USER-cvfydnwadpdj7vdon36z')) ORDER BY `user`.`id` DESC`

I think this leads toward a new <cacheKey, userPHID> user cache.

This leaves us with spaces and config queries uncached, but they aren't user-depedent.

Mystery Query: Where is this coming from?

oh

final class PhabricatorPeopleMainMenuBarExtension
  extends PhabricatorMainMenuBarExtension {

  const MAINMENUBARKEY = 'people';

  public function buildMainMenus() {
    $viewer = $this->getViewer();

    // TODO: This should get cached.
    ...