The fundamental disagreement here is over what qualifies as a
"wishlist" item, aka a feature or added functionality. And what
qualifies as a must-fix bug.
Priorities are context sensitive. If this were early in the cycle then
working on bigger impact features like conflict resolution code might
be more important because it's important to get them into the code
base where other people can see if it solves their problems and the
behaviour can be tweaked. Fixing rare but outright broken things might
not be high priority because while they have to be done by release
nobody is blocking on on the solution before then.
On the other hand near release we stop trying to incorporate new
features and focus on basic bug features. The new features don't
become any less important to the users, it's just that they'll make it
into the next release. There will always be more features that can
help users and we'll always think of cool new things to knock off the
rough edges off what we have now and get it out so we can go back to
the playground for the next release.
You said "I think we should extend the time available to make sure we
have a sensible set of features for 9.0." Perhaps part of the problem
is that I couldn't understand what your patch did from the description
you posted and can't evaluate whether it's fixing a problem that makes
the current feature set incoherent. Can you explain what it does in
more detail so we can understand why it's necessary for a sensible set
of features?