An inexorable fact of software development is scope creep (which is why it's the core mechanic of Vapourware). Software systems start as one idea and over time develop layers of other functionality that push the limits of the original software specification. There are many causes of this phenomenon including developers adding things they think are cool, managers wanting their pet features added and needing to immitate competitors' products. The causes aren't important, what's important is that scope creep exists (or will exist) in all software.
As systems take on new functionality there will come a point that a new feature is so alien to the original design of the software that it actually can't be added. Using the Lego metaphor, this building a giant castle on a small turntable block. Eventually the castle will be too big to be stable and you can't add new supports because doing so will force you to lose the ability to rotate. Originally the turntable just contained a cannon turret, and the castle was just built up naturally around it. It was never meant to handle anything so big.
I feel it's important to make a distinction between scope creep — software gaining new functionality over time — and insane bugs wherein systems are merely poorly designed (i.e., the Minecraft effect). In a well designed system, new features can be added incrementally usually without affecting other features and causing nonsense bugs. Software engineers know that scope creep is inevitable and strive to write software that is capable of being changed later. In our Lego example, even though the turntable castle is unstable, it has no bearing on the giant Lego robot you've built nearby.
The important thing to understand about scope creep is the need to redesign the fundamental system occasionally. Once your rotating castle becomes unstable, you need to step back and build a more robust rotating base and move the castle onto that foundation. The trick is knowing the difference between when additional functionality has forced a redesign and when the new functionality is still covered by the original concept.
Assuming that software is designed incrementally, and that at every stage of development the software is re-evaluated logically to determine whether large parts need to be rewritten, it should be possible to examine software as it currently is to make educated guesses as to the nature of previous iterations of that software. In other words, functional archeology should, in theory, be possible.
Looking back upon our rotating castle, let's assume we have no idea that the castle can rotate. What we see is a castle that has a very perculiar shape due to its original requirement of balancing on a single two-by-two Lego block. We can also see that structures nearby (such as the giant robot) have very robust construction. Our conclusion is that this castle was built unstably not because of the inability of its architect, but because of a limitation in its foundation. More poking will reveal the turntable, but that is beside the core point: the limitations of the original design are what shape the perculiarities of the current design.
The same is true in software: areas where an application feels like it ought to be able to do something but can't even though the rest of the software seems complete and competitors' products can do it are very likely to be so far outside the original specification of the code that it simply can't be done without a fundamental architectural overhaul. If you see enough such holes in the application you can get a feel for what the original software probably was. Like an archeologist uses ground-penetrating radar to find buried ruins, you can find the original design in a scope-creeped system.
I'd like to use the recently released first-person shooter Brink as a case study to demonstrate what I mean. Brink is a great example, because it's a modern game that is similar to other games (such as Dystopia) while lacking some very obvious functionality (and having additional unexpected functionality) which I believe betrays a different original design.
Brink a standard cops-and-robbers team game. There's nothing about it that is particularly unique, rather it's just a combination of game mechanics seen in previous games, though not necessarily all together in one game. The important features are matches are team-vs-team games, characters are highly customizable, weapons are highly customizable and characters can gain new abilities as they level.
Each of those seem normal. TF2 actually has all of these features, albeit to a lesser degree. In fact, a lot of games have these features. Games that have features like this tend to have something in common: you level up in game, and you can do your resultant customization and levelling right in the game. This is not the case in Brink: though the game tells you you have gained a level and can choose what your new abilities are going to be, you must log out of your current game in order to do so. The same is true if you want to customize a weapon to make it more suitable for the current circumstances in your game: you have to log off, which defeats the purpose.
Our ground-penetrating radar reveals another out-of-place piece of functionality: when Brink is started the first time it presents to the player a short video detailing the two sides (cops and robbers) and why they are fighting. Fair enough. But then the game asks the player to pick a side before he can proceed. This would be as if TF2 asked the player to choose red or blue before allowing him to continue. In fact, Brink lets the player choose either team when he's in a game, so his original choice has absolutely no bearing on the gameplay. And he can take his cop character through the robber campaign and vice versa, so this choice has no bearing on the story either. It is as nonfunctional as a feature can be.
Why does Brink behave this way? Why is its functionality so weird in spite of being so otherwise polished? Why is it missing functionality that similar games have always permitted? I have a theory: Brink was originally designed to be significantly more RPG-like, wherein players would set up one character with one set of weapons and play this character as he was defined at the beginning. So he would have one team, one particular set of gear and a set of skills that wasn't meant to change very often.
Then, in playtesting, they realized that players needed to be able to change team in game, and class, and they could level up during a match. They tried to add these features to the codebase, but their network protocol wasn't able to handle in-game character updates, because it was never designed to do something like that. So they forced in team- and class-changing features but were unable to allow character, weapon or skill customization because their metaphorical rotating castle was already too big.
At least that's the best explanation I can conceive for Brink's oddities. I admit my functional archeology is nascent. I hope that Splash Damage realizes that its castle needs a better foundation.