Those two breaking changes are indeed completely independent, you could do them in either order.
But of course there are many more of them that would be sensible to schedule (I think), such as improving the isolation of extensions, to make it less likely that they break when upgrading OpenRefine. That generally means cutting off access to various functionalities (visibility of Java dependencies, Javascript entry points…), so generally breaking things.
This was discussed at length in this thread:
My reaction to the lack of consensus, by default, is to avoid making any breaking changes, and spend the remaining time I have on this project by working only on things that can be released seamlessly. It does feel like giving up on finding a consensus, which is sad of course, but I fear we simply don't have the team cohesion and quality of communication that's required to reach one. And there's a fair case for saying that OpenRefine simply is legacy software, that we want to maintain as is. Major improvements to it are perhaps a better fit for a ground-up rewrite, so a different project.