These concerns are why I tend to dislike the GPL.
This might mean it is not in useful to you but it doesn't make it bad. In other news your motor home is probably not the best option to commute to work and living in your car isn't the best experience.
I think you don't have this issue with more permissive licenses like MIT/BSD. At least then you have a chance of having the commercial-licensed one having all the fixes from the open-source version, in addition to its own fixes and new features.
(My understanding of open source/free software licenses can be quite fuzzy, so correct me if I'm wrong.)
But that's a feature of GPL, not a bug.
If you are a company producing code and trying to make a living from it, it's risky to release code as BSD/MIT unless you can afford to have someone clone it, close it and sell an improved version, passing it off as their own without giving you anything (like Microsoft did with the BSD TCP stack, and with NCSA mosaic for example). If you release as GPL however, that can't happen. It's much safer in that regard, and more socially considerate too, which is why it's the license of choice for most Linux distro vendors and other major open source vendors such as MySQL.
My point is that with GPL, the implementation of the fixes/new features is right in front of you, you see it, yet you can't merge it into your GPL-incompatible codebase. Let's say we are talking about a security fix that turns out to be really easy. Somebody patched it in the GPL version, the fix turns out to be dead-easy and obvious, but now you can't use the same dead-easy and obvious fix in your own non-GPL version because it would be a violation of GPL. So now you have to come up with a suboptimal, ugly fix. In this case, GPL makes it painful for the original author of the proprietary version.
If the fix is dead-easy and obvious ("change that = in a if statement to an ==", "add a check for foo", or "make this assignment a 1 instead of a 0"), the GPL license of patch A doesn't prevent anyone from creating (from scratch) patch B that does the same thing. For legal proof purposes, you probably want to ensure that the author of patch B hasn't seen the contents of patch A, though for something as obvious as the cases I present, I'm not even sure I'd worry about that.
1) You almost certainly can as long as it's trivial, or you didn't look at the fix but did it independently based on a description of the bug. Legally, it all comes down to whether your work was a derived work or the original, not whether the result looks the same.
2) That's the idea anyway! Allowing someone to copy the work of others into a codebase that doesn't allow similar copying is exactly what the GNU GPL is designed to prevent. It's a risk you take if you decide to maintain a proprietary fork.
And while someone using free software in a non-free fork can release the changes as shared-source leading to the same problem, this has rarely happened.
There BSD/MIT licenses don't prevent you from doing this either, though it's possible in practice it happens less. You can create not only closed-source proprietary forks of a BSD/MIT code base, but "source-available" or "shared source" proprietary forks, where the source is public but under a proprietary license that prohibits unauthorized redistribution or derivative works. There's nothing in the BSD/MIT license that requires you to keep your proprietary forks secret.
I consider your wording deceptive. Why do fans of GPL engage in this deception? Stallman, the FSF and everyone else agrees that MIT, BSD, Apache and other are Free (as in freedom) software licenses and conform to the FSF definition of free software.
Therefore your sentence should be "If the only license you have is GPL, it doesn't allow you to use those in certain Free ways (non-GPL Free ways) or in any non-Free way".
While GPL licensed software is undoubtedly free software, the GPL is not synonymous with free software and by it's nature it is at odds with all other licenses free or non-free. It is incompatible with every other free license. I agree that the virality of copyleft is incredibly useful to drive adoption and resilience of free software but it is not the only way software can be free.
There are multiple ways to drive software freedom: social pressure, standards, law reform, etc. Between a project developed behind closed doors with periodical GPL code dumps and no community and an MIT/BSD/Apache licensed project with a vibrant and involved community I think the latter is a lot closer to the spirit of free software and is a lot more resistant to close sourcing even without the added protections of the GPL.
From the point of view of a user there is not much difference between:
1.a software maker deciding to abandon the GPL and release future versions of a project as closed source
2.and a software maker deciding to incorporate MIT/BSD/etc. code into a closed source project
And both are equally vulnerable to being turned into SAAS. The GPL does not guarantee software freedom for the users unless there is no CLA (and there are multiple copyright holders like in the case of Linux) or in the case of a CLA there is some other agreement like the Qt-KDE.
To make clearer the issue MIT/BSD/Apache/etc. projects have with the GPL think of it like this: It is the same issue you would have if you have a GPL project and you want to use an AGPL library or if someone creates improvements to your GPL project and releases the combined work (yours + his/hers improvements) under AGPL.