timing issues - when to switch main, for example - and issues - get your release 1 changes in so we can close down main for release 1 and open up release 2.
Then there's the identification issue. Is 1.33 a release 1 or a release 2 or what revision? In the branch per release stream model, you have 1.1 to 1.N are release 1, then 2.1 to 2.N are release 2, and perhaps 3.1 to 3.N (or in some systems 1.1.1.1 to 1.1.1.N) are release 1.5. Not a perfect mapping perhaps, but at least you can tell without having to consult the branch history.
Then there's the "how do I make a change to release 2?" issue. The answer is simple. In the "main" strategy, it depends. In the branch per release stream strategy, you go to the release 2 stream.
On top of all of that, there the extra merging. Changes made to the release 2 stream before it became mainstream have to be artificially merged to the main stream. And what happens when I try to look at the history of such a merged file. There are now two paths backwards to the ancestor - one through the release 2 branch, the other through the release 1 branch. Which one is more meaningful?
Some complain that with the step model, your branching is getting deeper and deeper all the time. That's just a naming convention. You're history is growing all the time, regardless of the model you use. But your branching isn't getting deeper. Neuma's CM+ for example, uses two-dimensional branching whereby, although they remember the branch point for each branch, each one gets a top level identifier so that you can always express a particular revision using the branch id plus the relative revision number (2.12, ab12, r2-12, etc. depending on the format you choose to use). When you look at a file history, you have a nice 2-dimensional tree, with branches being a first order object, and revisions underneath each branch.
These may appear to be minor issues, but they cascade on one another. For example, some will hold off making release 2 changes until release 2 is the main branch, causing unwarranted delays. Others may be prevented from checking in their changes because of the state of flux of main, causing, perhaps, the need for parallel checkouts and reconciles where none should have been required. It doesn't take a lot of complexity to complicate a model - just a few little things here and there and some people will get confused and make mistakes, which then have to be unravelled. 
Branch per release stream is a simple model. Simple for developers to understand and simple for product managers to understand. And even your CM tool can more easily understand what's going on, making it easier to automate the CM functions. Branches don't merge. Instead, specific changes are merged from one stream branch to another as necessary. Eventually branches are retired.
Branch per release stream sounds like more branching, but in fact, it's just less merging. You need to support each of your main release streams, so you might as well start them out on separate branches to start with. Then there's no need to merge back into a main branch. Now this does not mean that you branch every file into each branch. You only branch when you need to make a change specific to the stream and there is not an existing branch for that stream. It still pays to plan your work. Don't start work on release 3 of the database subsystem
About the author
Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
