The Intel 8086 is in turn backward-compatible at the assembly language level to the 8-bit Intel 8080 and 8008. Intel provided a tool to machine-translate 8080 ASM source code into 8086. For the most part it was fully automatic, but there were a few instructions that needed manual intervention. Even so, it made it cheap to port 8080 software to 8086, providing instant software for 8086 and 8088.
The automatically-translated code used 8-bit registers and didn't take full advantage of 8086's 16-bit instructions, so you didn't get any performance improvement. If memory serves, the new 4.77 MHz IBM PC ran early software slower than an 8 MHz Z-80 computer in spite of the PC's 16-bit 8088 processor.
I used to help manage compatibility at Symbian (the smarphone operating system company), and I agree it's a constant dilemma. If you want your customers to buy your latest product, they need to know how much time and effort will be involved in migrating their old applications, hardware, working methods and so on. It's no good just saying "we don't support the old product any more" and expecting customers to stay loyal ([cough] Windows XP).
It's a dilemma for customers as well. They need a migration path - information about how and when to modify anything that relies on compatibililty with your product so they can assess what will continue to work after an upgrade and what won't, what the costs and timescales will be and weigh those costs against the benefits of upgrading. If you spell that out for customers, they will tell you how much effort to spend on compatibility. As you say above, "Some of the best ideas come from our customers."
You may be suprised to find some old (and even new) features are almost completely unused and hence there's no point spending time and money supporting them. They should be deprecated and eventually removed. On the other hand, you may be pleasantly surprised to find that some original features you thought were obsolete are actually still heavily used (even though better alternatives exist) but no-one complains because they "just work".
If breaking compatibility is more in your interest than your customer's, it may be worth making a migration tool or offering free assistance if an upgrade goes wrong.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.