Interview Questions

[TheGreatCthulhu]

As nuzzle said, this is a question of software design. Design principles and practices, as well as best practices in general, are not set in stone, and are not to be followed with religious zeal: they all have some reasoning behind them, their pros and cons, and thus a defined domain of applicability. If the requirements for your software put it outside of this domain (or not entirely within it), you make some effort to gain a deeper understanding of the system you're building, and then either modify the design principle/practice, or throw it away entirely as inapplicable in favor of something else.

Are many of you going to develop alternatives to the STL? The concerns you're expressing about the virtual destructor appear to me to be related to rather specific cases - cases where the practice shouldn't, but more importantly, where it doesn't have to be followed. No one's forcing you to do anything. A principle/practice should be considered on the basis of its applicability, and it should be estimated how relevant and beneficial it is in general (what nuzzle called "far-reaching", if I understood correctly). Once you've made that estimation, you can decide how often and in what cases you are going to follow this principle/practice (if at all).
Whether the compiler should issue a warning or not is a different matter.

OReubens' argument was that it "can save a lot of headaches somewhere down the line", and that the cases "where a virtual destructor would actually cause problems and where it needs to be non-virtual are very rare". All you have to do now is decide if you agree with this observation or not.
But that's from your personal experience and most likely from the perspective of a field you're working in. Language (and compiler) designers, on the other hand, have to analyze how the language is (or is going to be) truly used in the majority of cases (possibly giving some important cases more weight than others), and make language design (or compiler design) decisions based on that, including whether to support a principle or a best practice through the language, through compiler warnings or otherwise, doing their best not to jeopardize how people use the language for other things. Tricky business...