We're increasingly building up entries in RuntimeEnabledFeatures.json5 which are confusing because the feature is enabled (in code) on some platforms but not others, eg. in runtimeEnabledFeatures.json5:

    // WebBluetooth is enabled by default on Android, ChromeOS and Mac.
    {
      name: "WebBluetooth",
      status: "experimental",
    },

Then in runtime_features.cc:

// Web Bluetooth is shipped on Android, ChromeOS & MacOS, experimental
// otherwise.
#if defined(OS_CHROMEOS) || defined(OS_ANDROID) || defined(OS_MACOSX)
  WebRuntimeFeatures::EnableWebBluetooth(true);
#endif

There are several more examples including MediaSession, PaymentRequest, and now NotificationContentImage: https://codereview.chromium.org/2814553002.  I'm sure there's more I don't know about that don't necessarily have a comment in RuntimeEnabledFeatures.json5.  Comparing webexposed expected output across platforms (see  issue 711292 ) should help identify the complete list.

Talking awhile back with ktyliu (who build the json5 infrastructure here - https://codereview.chromium.org/2656163005/) I think it would be pretty trivial to add an 'os' option, so we could remove the code above and just have something like this in the json5:

    {
      name: "WebBluetooth",
      status: "stable",
      os: ["android","chromeos","mac"],
      other_os_status: "experimental",
    },

other_os_status would default to "test" and so probably not usually need to be specified unless there's actually an experimental implementation we want to expose to other platforms.  This would probably be implemented similarly to the existing origin_trial_os option. 

To minimize confusion we might want to force other_os_status to never be 'stable'.  I.e. in this case: https://codereview.chromium.org/2814553002 you'd have to say:

    {
      name: "NotificationContentImage",
      status: "stable",
      os: ["windows", "android","chromeos","linux"],
    },

rather than use:

    {
      name: "NotificationContentImage",
      status: "test",
      os: ["mac"],
      other_os_status: ["stable"],
    },

But this could be up for debate.

We'd want to add some documentation at the time of RuntimeEnabledFeatures around guidance on how to use this, including:
 - wherever possible tests should be enabled on all platforms (which is why other_os_status defaults to test, not disabled).  Eg. most LayoutTests don't run at all on Android so we rely on the test coverage we get on Linux and other platforms.  This can also make debugging easier.
 - In general we prefer feature to be shipped on all platforms, but when a feature doesn't make sense (or isn't yet ready) for a given platform it's often better not to expose the feature at all than to expose it but have it fail.  That way developers can rely just on feature detection.

luna, we've hit this enough times now (and fixing is probably simple enough) that I think it's becoming urgent so I'd like to call this Pri-1 for M60. Can you take a look?  If it turns out to be harder than I anticipate I'm OK with lowering to Pri-2.