Merging feature branches to release branch instead of trunk

I have a question about two source control scenarios, both with feature branches and release branches:

In scenario 1 feature branches are merged to the trunk.
In scenario 2 feature branches are merged to the latest release branch.

What are the consequences of scenario 2 compared to scenario 1?

What are the possible advantages and disadvantages of both scenarios?

More details of the two scenarios:

all development is done in feature branches
branching is always done from the trunk

Scenario 1 (similar to what is described in this SO-answer):

feature branches are always merged to the trunk
a new release branch is created from the trunk, when preparations start for a new release
after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk and newer release branches
changes to the trunk are merged to all feature branches

Scenario 2:

feature branches are always merged to the newest release branch
a new release branch is created from the trunk, when the current release branch no longer accepts new features and preparations start for final release
after QA and deployment from a release branch, the changes/bugfixes in the release branch are merged to trunk
changes to the trunk are merged to all feature branches and the newest release branch

Solution

Since branching is all about isolation (see "When should you branch), the difference between the 2 scenarios is the role you want the main branch trunk to have:

Scenario 2 is more adapted to a static role: trunk would be the representation of what is in production (and the occasional hot-fixes needed to be merge back to current feature and next-release branch)
Scenario 1 is more suited for a dynamic role: trunk is the integration for various feature, release branches being made from there to consolidate the features which will actually be part of the next release.