An summary on the discussion on Kusama Channel concerning this particular proposal, the right approach for the increase of validators and the use of Scheduler as a tool to do this happened on the Direction Channel:

In general, the Council worries Kusama Network is unprepared for a large jump in numbers of validators. The idea of increasing the number of validators in slightly small numbers seems more appropriate in this case.

The council agrees in the need of trusted, working setups with validators that are prepared and states that experimentation with the increase in the number of validators slots can go wrong if the new validators are not ready.

One of the general goals is to reach 1000 validators by the end of autumn: this would mean an increase of 100 validators monthly. Is this responsible?

Some conditions to have in mind when thinking about this goal:

• In general, with ⅓ of validators offline there is a high chance finality will stall. It is also dangerous to have ⅓ + low-staked validators.
• The safe thing to do is to increase only when the amount of validators waiting is relatively high, to make sure the chances of encountering prepared setups are higher. If all validators appear to be online and participating in block authorship over the course of a session, then the tolerance for adding more validators can increase.
• At the current pace we have one referendum every three weeks. It is a simple choice to go for a 75-100 bump every three weeks or some smaller bumps on smaller intervals (say 25 per week).
• A collateral but undesired consequence of violently increasing the number of validators is the increase in the use of cancel slashes: this is obvs a negative use of this function, and the general opinion is this should only be used on bugs.

In general, although community driven-increases are welcome, the council feels scheduled intervals with modest increases would be faster, smoother and less risky for the network.

• A path forward seems to be increasing the number of validators by a modest amount very consistently. A general rule governing this decision would be not to add more than half again as many slots ever. So 1 -> 1.5 is the absolute limit of what's safe, if you trust 100% of the validators currently occupying slots.
• To set this up, the use of the Scheduler seems to be a good tool: pre-scheduled governance changes can be called, following the logic "do this once every N blocks K times, then do this every M blocks J times"
• the need of testing the increases: testing more to see how large a solution will be on 1000 validators and say 100,000 nominators. The network design is quite optimised and produce small solutions, but requires testing. Checking the outcome roughly for the next set would be a good requirement for anyone submitting a proposal to increase. The use of bounties when ready by allocating a specific treasury amount to tests, including this one, could incentivise this.

https://github.com/paritytech/substrate/issues/6373 to improve the usability of the scheduler. https://github.com/paritytech/substrate/pull/6417/files introduces increaseValidatorCount to be used.