It came out of the discussion at
#2081873: Re-implement module disabling in a temporary/debugging capacity that is environment aware and explicit about risks to data integrity →
that there is need for Core to provide a way for modules that provide notifications to users during normal operation can be suppressed in "quiet mode".
While a module (or a site) is in "quiet mode", normal messages that would be sent by the system would be suppressed to some degree.
This functionality is distinct from a traditional "disabled module" because only functionality related to communicating messages to users would be prevented. Modules are expected to function normally aside from this change, and importantly can continue ensuring integrity of their own data and providing all other functionality as normal.
While a site could persist in "quiet mode" indefinitely relatively harmlessly (technically speaking), it would almost always be a temporary measure during special circumstances (like a major data migration) as the UX would be severely degraded for a live site.
The use case is "Migrate module, for example, temporarily disables modules such as comment_notify during migrations." - without disabling comment_notify (using traditional disabling methods), inappropriate emails would be sent by the system during migrations to real users.
Examples of functionality that could be suppressed:
- drupal_mail()
- drupal_set_message()
- watchdog()
- hook_requirements()
We may also want to consider a threshold of severity beyond which messages are suppressed. For example, do we really want to suppress REQUIREMENT_ERROR messages, or just info/warning messagse?
We may also want to consider a permission that allows certain users (administrators) to receive messages during quiet mode, as it's more likely that messages presented to administrators will contain information critical to maintaining site operation.
We may also want to consider optionally redirecting some messages instead of removing them entirely, like the way https://drupal.org/project/reroute_email can be used to safely test email functionality on dev/stage environments.
We may also want to consider a simple API developers could use to arbitrarily suppress functionality during "quiet mode" that Core has not anticipated a need to suppress.