Clarifying my use of the open/closed principle:
You are correct. You can take a strict view of the open/closed principle, understanding that any change at all is a potentially breaking change. And that is a useful principle to keep in mind.
There is a looser interpretation which is more generally usable:
The essence of the open/closed principle is that we should minimize the number of changes required to add new features to the software.
Open for extension means that we should be able to add new features or components to the application without breaking existing code.
Closed for modification means that we should not introduce breaking changes to existing functionality, because that would force you to refactor a lot of existing code, and in the case of a public API, would probably break a lot of software consumers that are outside your sphere of knowledge or control.
Getting nit picky about the particular details of how the open/closed principle works misses the point. In both interpretations, it works as a general design guide that is not tied to any particular language or technology, and it applies equally to functions, classes, and even compiled binaries and deployed SaaS APIs.
If you can’t see past one rigid interpretation, you miss out on how it can be more broadly applied in equally useful (in this case, I’d argue more useful) ways.