Each branch has a role. Branching for a feature is a good one as it allows the feature branch to specifically identify that role.
Always merging back to default implies that default is the roles of mainline, accumulation, and packaging - and this is where you are having trouble.
You should instead consider making a branch for the role of 'accumulation for the release' and then merging your features into the appropriate accumulation branch.
There is nothing saying you can't have multiple simultaneous accumulation branches. One branch for 'next target release' which also has the name '2.0' (multiple names on a branch can make understanding the intent of each easier - though it may also make it trickier to do all the name updates) and then another branch for '3.0'.
If your feature isn't intended to be in 2.0, but is intended to be in 3.0, merge it into 3.0.
Once you are complete with the 2.0 / next release branch, merge that back into default and release it. Then you branch again for the next release branch from default and merge 3.0 into the next release branch and continue from there.
This has the advantage that you can cleanly build the 3.0 branch at any time to see if there are troubles on the horizon - before 2.0 is even released. It also separates the roles and build policies for each branch allowing them be understandable.
Further reading (a favorite of mine when it comes to branching and source control): Advanced SCM Branching Strategies. In particular, it explains what each role is and how they work together. While its focus is perforce, it can be cleanly applied to git and other distributed version control systems. Once you read it, give git flow a read and see how those concepts are applied in that model.