"What doesn't are vendor specific items like IE6, and if you were developing specifically for that, well, then you made a terrible choice, especially if it affected your entire application stack."
Oh stop showing you have no idea about software development. It's not about making a terrible choice, without being psychic one cannot make a better choice than supporting the two browsers that are used by the vast majority of the market. Not planning to support it when that's the status quo, and there's no obvious sign of impending change is utterly retarded. The fact that things did change is due to the unpredictable nature of technology.
"So apparently, the only thing that needed changing in your case was the GUI. If you knew squat about web development, that would have been a relatively minor thing to change, provided that you knew what you were doing in the first place. Building to IE6 indicates otherwise however."
The fact you think this shows how utterly out of your depth you are. The fact you believe you can blanket say that the UI is a small part of any project is utterly retarded, how do you know this? how do you know what the scope and scale of the project is? Stop talking about things you blatantly do not understand and cannot know about.
"No, what I need to be able to do is take technology today, as it exists, pick the proper components, even if they are alpha/beta, and ensure that my choices are kept up to date and do what they need to do, especially in the alpha/beta area. It's called tracking your dependencies, and it's not accomplished by tying yourself to maven central."
So in other words, use an agile process. Which is exactly what you're telling everyone not to do. Right.
"Have you worked in the real world? Generally a project is envisioned, then estimated and budgeted. This happens at the beginning of a project, because generally shareholders (public companies) don't like to spend 50M on a project (promised functionality) and not receive a working model."
Yes, and that's the point of Agile. It's designed to work in the real world where the only way you can truly estimate the amount of features you can implement for a specific cost is to actually do it. Thus, rather than pick a number and set of features out of thin air as with waterfall, you just set a budget, and keep rolling until you hit that budget, and what comes out is what is possible against that budget. If early on it looks like you're not even going to get close to the features you wanted for the budget, then you stop sprinting and fail early. This is far superior to failing late as with waterfall where you've blown your whole budget and ended up with something useless. Agile caters to change. That's the whole point.
Your description of GM and agile just further highlights that you don't know anything about agile. Agile doesn't demand that there are no communications between teams and stakeholders. The whole point of the job of stakeholders is that they're getting what they need, and if they're not working with other stakeholders to make it fit then what you're actually dealing with are inept project managers, which, guess what? also make waterfall projects fail on a regular basis. Retardation isn't limited to agile, nor is agile a magic cure for it.
"I'm describing the real world, how people try Agile, and how they and Agile fails. You can keep dreaming that it works"
Okay, I'll keep "dreaming" that it works, along with everyone that uses it to succesfully deliver projects, you know, like everyone from Google, to IBM, to Microsoft, to those government folks you falsely claimed only ever use waterfall:
People deliver with agile, the fact you claim they don't is evidence that you failed to implement it, or used the wrong tool for the job. That's not a defect with agile, that's a problem with your project leadership.
I've delivered large (multi-year projects) with both agile and waterfall, (and hybrids in between) using the right methodology for the task at hand. It can work well if you use it in the right place (e.g. UI development as you indirectly admitted above). If you've always failed with it, well, it sucks to be you. But I doubt you'll ever get it right if you blame the methodology rather than your processes. Plenty of companies, and plenty of massive projects do perfectly well with it though, so saying it doesn't work is patently false, and saying they do more than agile is a classic no true Scotsman fallacy.
"In essence, I practice neither process, but a project management style that is more dynamic that grew out of understanding waterfall's short-comings and agile lately claims some portions of as its own."
Most people do, and there's nothing wrong with that. But pretending agile doesn't ever work is as stupid as pretending waterfall never works. On the contrary, if you're building a bunch of pre-designed houses then waterfall works perfectly well because you know how long it takes you to build such a house when you've done it so many times before. Similarly, when you're doing something highly iterative in nature to get right, like UI work, then agile also works perfectly.
As an aside, I find it fascinating that all your examples seem to dodge software development and focus on things like cars, and government non-software projects. That, coupled with your other comments doesn't half make it look like you really do know fuck all about software development, especially as you seem to believe that trends in the technology world are reliably knowable a number of years ahead of time.