If we encounter a case when our design, that uses some specific pattern, cannot accommodate a new requirement without some modifications, it won't mean that the pattern (doesn't matter which one) is bad and violates some good design principles.
It will mean only that our design is not prepared to gracefully handle such cases.
Is it a failure of our upfront design?
In some cases yes. But more than often it is a sign of either of the:
- Changing requirements.
- Insufficient domain knowledge.
You may and should consider your design carefully, but no matter how adaptive your system is, once upon a time either requirements will change or some piece of obscure domain knowledge will force you to change even the most well-designed system.
Is it bad that we have to modify our system in such cases?
Probably not. You can't design system that can be extended in any possible way without compromising other good design principles. Because such systems will usually sacrifice performance and(or) ease of understanding.
It is a guilty fun to read about similar overly adaptive systems on thedailywtf, but you don't want to end up maintaining one.
Won't it turn the system into a Big Ball of Mud?
If such changes will be made without any considerations about bigger design, then probably yes. But if you apply such changes with proper commitment to reconsidering and, possibly, refactoring them during the consolidation phase then you will be able to hold the entropy in check.
So, does the Command pattern violate the Open-Closed principle?
No. In most cases it is the system's requirements that make specific usage of this pattern not as open-closed as we'd liked it to be.