For 24.2.0 final, scheduled for 10 December, there will be a total of three tweaks on tap: increasing the garbage collection timeslice (as mentioned before), which should also help reduce memory usage by cleaning up more fully; again locking cores to one; and removing the blurred boxshadow from the video stand-alone document so that playback doesn't chug when the blur gets invalidated and must be redrawn. No other critical bugs have cropped up.
Oh, but before I could do that, trying to install gcc 4.8.2 caused MacPorts to try to rebuild Perl 5.12, which failed (even though I already had it on the system) due to a linker problem with Xcode 2.5. Forcing the install caused it to fail building cloog due to bad isl headers. Upgrading isl manually enabled it to complete and then I could build the other prerequisites and told it to ignore the Perl one, and finally I successfully built gcc 4.8.2 ... which then broke gcc 4.6.3 because of the new compiler libraries. One rebuild, a lot of cold sweat and about 24 hours later, the toolchain is working again and I'm crosschecking the libraries to make sure. As a result, we're on gcc 4.6.4 but 4.6.3 will still be supported, since it was known to work. All this to say that you should be very careful about MacPorts updates right now -- it is doubtful anyone is routinely testing port changes, let alone new ports, against 10.4 or 10.5 and several ports are already demonstrably busted. I need to backup /opt and then I'll try to submit fixes to the portfiles for 10.4 as I have copious spare time. It may be worth our while to generate a binary set of the toolchain components that can be installed separately to guard against this, since it will almost certainly happen again in the future.
I have a low threshold for not advancing to 26 even if it works, mostly because I don't want to be dropping source parity on a non-ESR release so close to an existing ESR branch, and because some of the stuff for Australis that is landing now is alarming and may not even be workable for 10.5, let alone 10.4, which may force our hand anyway. (But hey, I predicted our demise for Firefox 5, 10 and 19, and we made it through all of those releases; still, we've existed much longer than we've had a right to.) I'll make that decision based on what changes I have to make to get 26 to work. If these changes are unacceptable or impossible (or I can't figure out what to do in time), or the resulting product is iffy, then we stay on 24 and we go to feature parity. I'll decide this after 24.2.0 comes out.