I don't think there's any one answer that's right.
Generally speaking, when a language is relatively young, there's a lot more freedom to make relatively large changes relatively quickly. There's not a large base of existing code to break, so people are generally much more open to experimentation.
As the language ages, assuming it comes into wide enough user for anybody to really care, the base of existing code starts to place tighter and tighter restrictions on what changes can be made. Not only is there more code making use of more features so it's harder to guess what changes might break code, but people's expectations change.
Just for example, let's assume there were about the same number of people writing Ruby and Fortran. Furthermore, let's assume there was about the same amount of code in both. I'd say the chances are pretty good that a change that broke exactly the same percentage of each (and in a way that took about the same work to correct) would be a lot more acceptable to Ruby users than Fortran users as a general rule (at least assuming they saw it as an improvement).
I think a lot also depends on people's perception of the language to start with. People who choose a language because it's "cutting edge" are a lot more likely to put up with major changes that break a lot of existing code, if that's what it take to keep it on the cutting edge.
Another factor is the size and life expectancy of the projects for which the language is intended. A language that caters to relatively small projects or ones we know up-front have a short life expectancy (e.g., a web UI) can get away with breaking things relatively frequently, because it's unlikely many people are going to continue using the same code base for, say, 10 years any way. A language (e.g., C++ or Java) that caters more for larger, longer lived projects that may take, say, 5 years to get to an initial release, may be in regular use (and continuous development) for three or four decades obviously demand a great deal more stability.