Developers on the mailing list and end-users (in the forums) have been largely positive about this move to drop the aging and not actively maintained Mesa code. The only developer actively objecting to stripping out the old code is Luc Verhaegen. Michel Dänzer raises a (minor) interesting point though, "DRI1 is basically the only reason for the r300 and r600 drivers to still live in the light of r300g and r600g, but I believe they (along with radeon and r200) are still pretty far from dead on non-Linux OSs."
While there are no plans to immediately kill off the R300 or R600 classic Mesa drivers (since the R300/R600 Gallium3D drivers have taken over), the point raised is that these old classic drivers are still playing a role on non-Linux operating systems. In particular, the BSDs and Solaris/OpenSolaris.
The BSD distributions, Solaris, and other similar operating systems can't run the latest Gallium3D (and Intel classic) drivers from mainline until they support the needed prerequisites, which have come to be DRI2, GEM/TTM in-kernel memory management, and kernel mode-setting. These are all supported within the Linux kernel and designed around Linux interfaces, but aren't yet widespread in other operating systems.
There is the work I have been reporting on about FreeBSD bringing Intel KMS and GEM to their kernel, which will make it easier to run the Intel i965 classic driver with support through the latest Intel Sandy Bridge hardware. The latest FreeBSD patches (available from this Wiki page) are from around the Linux ~3.0 kernel with various modifications to make the Intel DRM driver work under the FreeBSD -current code-base. This Intel kernel support won't be merged prior to the upcoming FreeBSD 9.0 release and due to porting it will always continue to lag behind the upstream Intel developments in the mainline Linux kernel.
The Intel graphics support for FreeBSD (and mostly other non-Linux operating systems too) is what's supported by user-space mode-setting and Intel's older code-paths before they were stripped away from their mainline tree.
However, this FreeBSD upbringing isn't focused on supporting TTM (the Translation Table Maps memory management) and with that, no Radeon or Nouveau DRM driver support. Nouveau won't work on the *BSDs and Solaris until that point since its mode-setting is KMS-only and also only implements DRI2. Open-source Radeon graphics work for the BSD and Solaris operating systems for the older hardware that has user-space mode-setting (via the xf86-video-ati DDX) and classic Mesa can work (~R300 ASICs), but newer generations require the Radeon DRM kernel driver for bringing up any form of acceleration (2D included), DRI2 is only supported along the KMS paths, and AMD is beginning to implement support for new ASICs only for KMS with no support for the more-portable user-space mode-setting.
There's been some work to port R600-era code in DragonflyBSD, but at last check it was still an experimental feature and not part of the mainline code-base. There were also previous efforts for Solaris to do things like port the Nouveau stack, but who knows what Oracle is doing to Solaris now and the efforts within the OpenSolaris/Illumos communities appears fragmented and experiencing some rot.
The FreeBSD Wiki mentions the DRI drivers they do support. These FreeBSD DRI drivers include Intel i915, ATI Mach 64, Matrox G200-G550, ATI Rage 128, ATI Radeon through X1950 (pre-R600), some Radeon R600/R700 ASICs, S3 Savage, SiS 300 series, 3Dfx Voodoo Banshee through Voodoo 5, and VIA Unichrome. VIA Unichrome in fact is new to FreeBSD 9-CURRENT. Many of these supported DRI drivers (e.g. Savage, SiS, VIA, 3Dfx) are what's going to be dropped from Mesa.
While FreeBSD may support them, it doesn't change the fact that the hardware is mostly ancient and that upstream Mesa/X.Org developers are just concerned about Linux support. Most of these developers just don't care and/or don't have the time and resources to focus upon supporting these operating systems that have an even smaller market-share than Linux. Finding BSD developers working upstream on these graphics components is also rare, it's not that the Linux developers are rejecting their work.
What should be done about open-source graphics drivers for non-Linux operating systems? Should free software projects handicap themselves and limit their innovations simply to be compliant and friendly with more operating systems?
Killing off these old Mesa drivers and other old code-paths will eliminate more than 100,000 lines of code. There's around 86,000 lines of code of old DRI1 drivers, another 35,000 lines for obsolete Windows drivers, over one thousand lines of code for the fbdev software driver, and around another one thousand lines of code to be stripped from the core/DRI area thanks to these drivers going away. More areas of fat can likely be trimmed too as Mesa core is further cleaned up and hopefully made more friendly for the needs of today and the future.
It's not open-source, but the best graphics driver option for BSD and Solaris users is using the proprietary NVIDIA graphics driver. Thanks to the largely shared driver code-base with the Windows/Linux builds, NVIDIA does provide official (and fairly good) support for x86/x86_64 FreeBSD and Solaris. AMD doesn't provide any binary-only (Catalyst) drivers for these operating systems. Using the NVIDIA binary driver is really the best and most reliable GPU driver option for these operating systems.