While the hang watching logic was simplified as part of  issue 804345 , it still isn't great.

ThreadWatcher::GotNoResponse() still hides reports if no other registered threads are responsive. In practice now that only UI/IO threads are watched, this means if we get a hang with both threads involved we won't catch it...


  // Crash the browser if the watched thread is to be crashed on hang and at
  // least one other thread is responding.
  if (crash_on_hang_ && responding_thread_count > 0) {
    static bool crashed_once = false;
    if (!crashed_once) {
      crashed_once = true;
      metrics::CrashBecauseThreadWasUnresponsive(thread_id_);
    }
  }

This seems to be happening in the wild because hang reports for the IO thread had stabilized around 125/day on Canary after r531510 and now after removing dummy threads in r532369 (i.e. now less threads to generate |responding_thread_count > 0|) this appears to be stabilizing to a lower crashes/day count (data still incoming) :

https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20product.version%20LIKE%20%2766.0.%25%27%20AND%20expanded_custom_data.ChromeCrashProto.channel%3D%27canary%27%20AND%20expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20expanded_custom_data.ChromeCrashProto.magic_signature_1.name%20LIKE%20%27%5BThreadWatcher%20IO%20hang%5D%25%27&sql_dialect=googlesql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D

A follow-up to  issue 804345  is required IMO; hence filing this separate bug for investigation.