I find Uncle Bob's definition of SRP makes far more sense if you change it from "responsibility for something" to "responsibility to someone." That is, there should be one and only one person, or business role, who would want a given class to change. The "one reason" then becomes "That guy over there gave me a business justification for it," and nothing else really matters. It's just as easily read then as "a class cannot serve two masters."
That matches well with the original guiding principles for software modularity: modules should encapsulate deferred or changing decisions, nothing more or less.
I think the point is you cannot predict what decisions are going to change or be deferred. That's why I like the interpretations of this that try to make change in any direction more reasonable. Otherwise you get people building things like abstract factories "just in case".
> The problem with SRP is it's hard to define what that "one reason" is exactly
Sure it's hard to automate it. It's one of those subjective, experience-based factors that keep humans like me in a job. I never thought that it was a rule that can be mechanically applied.
> sometimes really want is just a function
summed up nicely here: http://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-funct...