To clarify, this does not include intentional easter eggs or back doors. Programmers love to use the statement "It's not a bug; it's an undocumented feature," but this discussion needs a new perspective. How about... it doesn't matter. Some beatures might be intentional while others are not, but that is still having the wrong conversation. The bigger question is "How should or would you like it to work?" This might sound like a loaded question, but it's an important ice-breaker to get the conversation started and focused. The question of bug vs feature is irrelevant to end users. They have a problem and are looking for an answer/resolution.
Unfortunately, defining something as a bug or feature is an internal business process that has gone awry. It never should have been made public. Classifying something as a bug or a feature is important for internal development tracking systems. They help document and track development efforts in a systematic manner. These systems help clarify the health and direction of software development. Although these are vital to any organization, it's important to remember that behind each beature is a real person. Sometimes developers can fall prey to process and loose sight of the larger picture. As good stewards of software development, programmers should strive to provide the best experience possible. This can be accomplished through a servant mindset and good business decisions. End users are the reason that development exists. It's prudent to respect their time and needs. Nobody wants to develop the software people used to talk about.