Something confusing about Single Responsibility Principle

Question

1)

In fact if two responsibilities are always expected to change at the same time you arguably should not separate them into different classes as this would lead, to quote Martin, to a "smell of Needless Complexity". The same is the case for responsibilities that never change - the behavior is invariant, and there is no need to split it.

I assume even if non-related responsibilities are always expected to change for the same reason ( or if they never change ), we still shouldn't put them in the same class, since this would still violate high cohesion principle?

2) I've found two quite different definitions for SRP:

Single Responsibility Principle says that a subsystem, module, class, or even a function, should not have more than one reason to change.

and

There should never be more than one reason for a class to change

Doesn't the latter definition narrow SRP to a class level? If so, isn't first quote wrong by claiming that SRP can also be applied at subsystem, module and function levels?

thank you