Situations where maintenance mode is useful/needed:
1. When the system (hardware) is in transit from the location where it was installed to the site where it is to be used in production.
2. When the system is down for other maintenance (software patching and updates, OS configuration changes, hardware reconfiguration and other external factors causing planned or unplanned downtime).
The above outlined method for installing new DPs to remote locations is widely used for various reasons (For example to have a dedicated team at one location install machine and to avoid having to copy a large content library across WAN links). During the time in transit (which is usually between 1 day and 2-3 weeks), the ConfigMgr site server will only know that the DP server is unreachable on the network.

Advantages with a maintenance mode option:
- The status system should/will mark the system as being in the fully expected maintenance mode state (no error condition).
- The log files for components actively working with the DPs will not be cluttered with information about attempts to work on packages targeted to the off-line DP.
- We will not have various error status messages generated regarding the distribution points and its packages during the planned off-line time.
- The Distribution Manager (DistMgr) / Package Transfer Manager (PkgXferMgr) pipe will not be burdened with and slowed down by requests for systems known to be offline.
- Packages targeted to systems that are in the maintenance mode state will not be labeled as failed after the retries are used up, but rather that they are in a “waiting” (for the DP to get out of maintenance mode) state.

The change requested:
The primary ask here is to let DistMgr and PkgXferMgr know that they should not need to work any request targeted to DPs that are in maintenance mode. If they are currently working on such requests, they should stop doing so and postpone the request until the DPs status changes.
It will also be good, if DP systems in the maintenance mode state are not considered when clients make content location requests.

Today it's only possible to orchestrate software updating based on a membership in collections.
This is however rarely enough for more complex setups where you might have back-, middle-, and front tiers in your setup.

Therefore I recommend adding a dependency system between computer objects, so that you can orchestrate at least the following:
1) Which tier of servers are patched first, second and third etc.
2) Reboot order between the different tiers which includes an accept of one tier being fully patched and rebooted before the next tier is begun updating.
3) Ability to choose between warning or rollback if a single server fails updating - however this should be possible to decide based on each tier. (you often care more that a database server is identical than a webfrontend).