I think such a strict schedule/plan can only work with a more, let's say, "disciplined" team. The FO dev team is a more "loosely" organized group. While there are some general guidelines or directives given by the project leads on what we want contributors to work on, basically people work on what they are currently interested in.
Which is why it's usually quite unpredictable what a release cycle will actually be about in the end, at least to a certain degree. What is actually going to be worked on next depends on what the currently active main contributors pick up. The project leads only give out suggestions, but we do not "command" the rest of the team the way it's done in more strictly organized dev teams.
That has certain advantages and drawbacks of course, but it's the way this project has been working for many years now.
So, feature freeze basically happens when the release branch is created, because that gives more control over what gets cherry picked into the release branch (and thus included into the release). Usually only fixes for bugs and balance issues, or things that polish something are cherry picked. Cherry picking of new features is a rare exception, which needs a good reason.
To focus playtesting on the release branch, the weekly test builds are based on it until the release is out, so that takes care of the release branch getting proper testing. Usually it takes several weeks at least, if not a few months from the creation of the release branch until the release is out, so plenty of time to get all the bugfixing, polishing, balance fine tuning, translation updates in.
That approach has worked reasonably well in the past.
That said, I'm open to suggestions for change. If the majority of you guys think that a more strict release procedure (with freezing of master etc.) would work better, feel free to open a thread (on this subforum) and start a discussion about it. But please do not continue it here, this thread is dedicated to the 0.4.10 release.