This is, in fact, correct. As someone pasted earlier in this topic thread (the response I gave to him via e-mail about "what is the changelog"), new releases of MobileSubstrate tend to correlate with major new releases of extensions as more bugs tend to be found. This release is also correlating with some new extensions that are coming out this week from OpenHebrew and Phoenix Consulting, which have been providing me feedback and bug reports over the last few weeks.
Unfortunately, /every/ new release of MS kills some people's phones (of course, I use "kill" in a simple fashion: you can /always/ restore your phone with iTunes and then load a backup), and that pretty much can't be fixed. The problem is that people have all kinds of weird extensions installed, and expanding the ability for extensions to touch more and more processes and functions means that these extensions get more power. What I'd expect is that the people who are experiencing issues are using an extension that was not coded correctly to load only into the processes it needs to load into (using the MS plist filters), and are therefore being loaded into the new processes that MS is capable of effecting.
Similar issues occurred when MS was fixed to handle itunesstored a few months ago (correlating to the release of Unrestrictor3G), mediaserverd some time after that (correlating to the release of some version of Music Controls), and now we are seeing some with CommCenter, locationd, etc..
Unfortunately, as I described via e-mail, the actual functionality of MS is only something a developer would love. What it does is it disassembles functions in memory, replaces them with redirects, and "moves" the original code to a new location. Its ability to "move" the original code is key: I frankly think MS would qualify as a good Masters Thesis project.
When MobileSubstrate is moving code, it can read it wrong, and then cause corruption by copying out worse code. Often this is due to it seeing something it doesn't know is important, but sometimes it is because it actually saw the wrong thing in what it was reading.
These bug reports tend to come in in giant waves when new versions of Apple's firmware are released, as Apple makes changes to both their code and their /compiler/, making the new code that much more weird looking to older versions of MobileSubstrate.
In particular, 3.1 has seen some major advancements in Apple's Thumb2 compiler, which is being used to compile for the 3GS, although improvements have also been seen in the branch handling for normal Thumb (what we are seeing more and more code be compiled to for the older devices).
Unfortunately, Thumb has a /large/ number of instructions that MS must be intelligent about moving to not cause damage. ARM, a simpler instruction set, which was what almost everything in 2.0 and 2.1 was compiled to, was very easy to do these relocations to, and I actually did some statistical analysis to say "MS is 99.9% complete". My thumb completeness, however, is probably only 80% right now, and versions of MS from before today are much much lower.
Unfortunately, when I fix these, all I can say is "omg, I can't believe this used to work at all".
In the process of improving the loader and the instruction decoder, MS is then able to inject into more processes that it previously was unable to. This means that extension developers are able to leverage more control over the system. This means that existing extensions may end up in places that their developers weren't expecting.
However, this is entirely due to them being shortsighted. MobileSubstrate has a specific mechanism that everyone should be using for specifying what processes their extension loads into. Also, developers should not be making any stupid assumptions about what will randomly be laying around that process. I will say that I've actually been running all of the extensions I commonly use (including WinterBoard, Backgrounder, etc.) inside of CommCenter (the phone controlling daemon) for weeks now, and I've made certain that there haven't been any problems.
Of course, these processes should never end up in CommCenter to begin with, at least if people are doing what they are supposed to be doing.
What this all means is that I only know of a single release of MS that has ever caused a bug that was MS's fault. While I've retracted many releases of MS over the years, every single time was just to cause a momentary lapse in bug reports so I could find the developer that screwed up and get him to fix his extension.
What users need to be doing is explaining: what extensions did you have installed when you experienced problems? If we can isolate down a pattern, such as "anyone using FiveIRows ends up with a slow phone that crashes all the time" then we can A) get that extension fixed, B) get users to upgrade, C) if it is popular enough, mark MS as "breaking" the old extension versions with APT's Breaks:/Conflicts: mechanisms, and get on with our lives.
To say this again: while new MS versions are likely to come out, they are unlikely to really help with the problem of broken extensions. I can't fix broken extensions. I'm not using the extensions you have, I don't know why they are broken, all I can say is: this thing doesn't work. If you load some extensions into Skype, Skype crashes. That isn't MS's fault, despite the fact that upgrading MS now "caused" the problem.
All of that said, MS's SafeMode is designed to keep you from simply being "screwed" (although it can't save you from being "slow"). Given that more extensions than I had hoped are loading themselves all over the system and scribbling over random processes, I implemented a CommCenter safe mode in 0.9.3087, as I mentioned on Twitter (and at the end of my form e-mail on "what is the changelog").
So, /please/: if you are in a position where you are having issues, don't just tell me "MS doesn't work". I need a list of extensions you were using, as best you can remember, so I can try to figure out A) if that extension is simply destroying your system in a way MS SafeMode could never save or B) I need to look into a better SafeMode mechanism that is much much much more anal.
