Feature Weenie

A FeatureWeenie is one who obsesses over features and features and features - sometimes dumbfounded or unfounded features.

As opposed to someone who disdains features... like a RealProgrammer? (HaHaOnlySerious)

Much software today has plenty of features.. maybe 90 percent of them unused.

Generally incorrect. Maybe 10% used by any one group, but a different 10% for each group.
Oh, so for example how many people use the NOT feature in Ruby? A feature worthwhile adding would be the AND operator in addition to the NOT operator. A feature not worthwhile adding would be two Back Buttons in your web browser side by side, one with a green arrow and one with a blue arrow that do the same thing.
UI frameworks ought to be flexible enough that, if you wanted to, you could put two back-buttons on it, side by side, such that one has a green arrow and one has a blue arrow and they do the same thing. You don't need both, of course, but that flexibility gives everyone the freedom to choose between blue and green, and probably choose where the arrow appears (on which side), among a number of other things.
Two buttons does not give anyone justified flexibility, it just confuses people. Justified flexibility is an opinion, but having three or four back buttons or nine of them... at some point humans agree about non justified flexibility per the situation at hand.
But the UI framework being flexible enough that, if you wanted to, you could put two back buttons on it, DOES give flexibility. Read carefully.
No that is a bug, it should ask you "why are you idiot enough to use two back buttons, do you really want to do this and report your idiocy to our bug repository over TCP/IP?"
The UI framework shouldn't tell you it's a bug unless you ask it to tell you it's a bug - i.e. by specifying, explicitly, the intent that there only be one instance of each operation (or maybe the 'back' operation in particular) available to the user, regardless of how you or the user attempts to configure the system. Perhaps I'm more from 'the customer is always right' school of thought, here.
And it just adds more bugs and maintenance if there is an idiot light in place to tell the idiot to not put two back buttons there so maybe we should just not allow him in the first place to drop two back buttons, or maybe we should allow him to drop two back buttons but not implement the idiot light.
So you'd rather treat everyone else in the world like an idiot rather than offer flexibility despite the fact that setting up checks and tests - the feature you require to ensure there aren't two back buttons - is what will really cost you extra maintenance and bugs, especially as the UI framework implements related features that allow, say, buttons in places that buttons didn't used to be. LessIsMore when it comes to 'checks' that aren't related to 'sensors' or 'safety'.
Sometimes it is unsafe to create two back buttons. One may have an uninitialized event, and reference to nil memory...
Nothing about having multiple 'back' buttons implies lack of safety. If you need safety, you acquire it from programming discipline, whether it be SelfDiscipline (e.g. checking your pointers) or BondageAndDiscipline (leveraging a type system). This is true no matter how many back-buttons you have. And any discipline-solution is better if it applies to ALL your buttons, and not just to 'back' buttons.
Which requires more code. Proving my point.
You make an invalid assumption. It actually takes no more code to make a check that applies to all buttons than it does to write special code for the case of forbidding two 'back' buttons. It likely takes an order of magnitude less code to make a check that applies to all buttons than it does to handle a larger variety of special cases. LessIsMore in this case.
One single button declared as TBackButton on TForm1 is a lot less room for error. You don't even have to give a warning to the user that he cannot create two TBackButtons because there is only one TBackButton in the first place, reducing the complexity immensely. Dynamically creating several buttons is nice.. but not always needed. Most GUI applications do not require dynamically creating several OK and Cancel buttons in a ShowMessage? window, for example.
Creating one single button declared as TBackButton is the beginning of an approach that creates an order of magnitude more work. Now, instead of just attaching 'TBackButton' as a 'Button' associated with an image and attached to a 'back' script, you need to create a special button to go 'back'. At this point you could still create a generic button, but it is more likely you'll add another special button for 'OK' and for 'Cancel', etc. Each time you write code for these, you have the opportunity to introduce errors. In a sense, each new button becomes a new 'feature'. So, after a vast increase in the effort you put forth, you managed to create a system that is both less flexible and ultimately more prone to error. And for GUI applications, flexibility is a benefit. If you don't want multiple buttons, simply don't tell it to have multiple buttons. If you suddenly need a special button for a special 'show message' window, you add it. The result is quite simple. And if you want templates or inheritance, there are plenty of fine approaches to getting it - cloning, procedural construction of a button-object, logical inheritance to a button object, etc. And if you really wanted, you could still add your specialized code to... e.g. issue a warning or error if two buttons with the same script (e.g. 'go back') are displayed to the user - this code wouldn't need to be specialized to handle your TBackButton along with every other 'special' button you might make. LessIsMore - a more generic specification takes less detail and less code, and gives you more flexibility and more extensibility in return. You gain dynamic GUI, too, but that wasn't even the intent, which was very simply: to avoid extra work.
Using an array of buttons, versus one button is more dangerous. Or say a collection of buttons, or a list of buttons.. now we can go out of bounds even, or corrupt memory...
The safety argument won't fly here, either. Nothing in the above discussion implies corrupt memory or bounds errors, or even the use of arrays.
Are you going to magically manage your buttons using some non-array based collection or list? or are you going to create a dangling object that is not part of a list? i.e. New(Button) New(Button2) oops now we can't free them. Darn, because they aren't even managed in an array or list of some sort.
The language-default unbounded collection will be sufficient - a deque in C++, or a list in OCaml or Lisp, or a full table for languages that use those. If I had to use C, I'd be torn on whether to use a generic void* managed list or an array with realloc (both are bad for safety, but I could write the code once and be done with it for either of them (using much SelfDiscipline). Anyhow, there'd never be a need for anything more optimal unless the number of buttons was often very large (e.g. over 100), which is quite unlikely given the human need for uncluttered interfaces. I can use any of these without bounds errors, without corrupt memory, and without magic.

Features cause bugs and add to complexity of software. All software has bugs. The more features, the more room for bugs.

True. The easiest way to have software without any bugs is to have software that has no features whatsoever.
The world population is quite high. Hmm. The easiest way to have Earth without any problems is to have Earth that has no...
Indeed, that would work. So, I suppose I must conclude that FeatureWeenies are people who want other people on Earth and who are willing to accept bugs and problems, whilst people who dislike bugs more than they like features would prefer the world be composed only of rock.

It's a bug.

Nope it's a feature

It's an effect.

It's a cool effect, and a cool feature, and a cool bug.