Normally a change such as this would be unacceptable because it impacts backward compatibility. We have a process for this kind of thing: http://www.scons.org/wiki/DeprecationCycle. As it says there, "SCons takes backward compatibility very seriously." However, in this case these source-control tools are pretty ancient and none of the developers use them so they are hard to support. So I would be OK with shortcutting the deprecation cycle for this: announcing that we're removing these tools from the defaults in one release, and then making the change in the next.
As for m4, that is available on Windows via cygwin and msys (whether you use cygwin or regular python), so I would not be in favor of removing that even on Windows. RPM however could be omitted on Windows since I doubt it would work there, even with cygwin rpm tools.
Here's how I'd like to address this.
Make a PR with just the Windows RPM and m4 removal. That's OK for next release. Just barely, because Windows users could still be using cygwin m4 in a non-cygwin python, but it's probably enough of a corner case to be OK. Add a note in CHANGES that it's an incompatible change but we expect the impact to be very minor. (I can wordsmith that if you like.)
Then as a second PR, let's start the deprecation cycle for the source-control tools. All we need here is an announcement in CHANGES, and a suppressible warning when they get used.
I'd like to put the next release out soon, because of the doc issues with 2.3.1 and there's already some nice contributions. So these can go in 2.3.2, and after that you can submit a PR to actually remove them.
Perfectly fine with me, but no prospects when it may happen. Especially with the wording.
It may be useful to save a patches for the next release saved in repository, so that people can apply and test them for this release. I think patches and not branches, because patches could be applied independently.