Disclaimer: I've only recently decided to Stop Worrying and Love the Scrum, so my perspective on the subject may still be heretical.
That said: I think these are not failure modes that can be laid at Agile's feet. They represent a situation that Agile quite explicitly does not even attempt to fix. A key part of the (for lack of a better word) Zen of Agile is that on anything above the smallest of scales, it's impossible to promise both a feature set and a due date.
To an approximation, that's what the whole sprinting thing is all about. It's breaking things down into bite-size pieces that are small and simple enough that you can hit milestones on deadlines with something approaching regularity. But on top of that you've got the overall development arc, and on that scale there are (or should be) no promises made about what's going to be happening on any sprint past the current one. The point of this is to buy the product team flexibility: Either the flexibility to adjust the requirements in response to new information that's discovered during the product lifecycle, or the flexibility to adjust the number of sprints that will be needed to achieve a given feature set in response to new information that's discovered during the product lifecycle.
In short, this is a feature of Agile not a bug. It's nothing more than being realistic about an immutable law of the universe: The more rigid you need to be about deadlines the less rigid you can be about requirements, and vice versa. Product teams have a professional responsibility to be honest about this fact. Customers and managers who aren't comfortable with it are free to restore their sense of certainty by building ample buffer space into the schedule.