I don't think this is entirely correct. If you write in Native (C/C++) then true, it won't run on WP7. But if you write in C#/Xaml you could have targeted your app to WP7 and I believe it will run on both WP7 and WP8 -- of course this will preclude you from using whatever now hardware capabilities in WP8 only.

I think the Native C/C++ is the right move though. The "easy to port to IOS/Android" point is important, and I think going forward that would/should be the model for web development, unless Webapp is sufficient for your purpose, or that you're willing to develop your app in 3 languages (ObjC, Java, C/C#).

That said, I'm sad that my (otherwise very nice) Lumia 800 is getting the WP6.5 treatment.

Why? There is a Manifest file where you specify the features your application is using. I would imagine that if you leave out the new, hardware dependent stuff it should run just fine? You can do something similar already by opting out from supporting phones with constrained RAM. Those applications are then made unavailable to certain devices in the marketplace. I admit that there has been no mention of this how it's supposed to look like with regards to WP 7.8/8 so it needs some clarification.

I've heard a lot of conflicting info about this. How can you be sure? Could you link to your reference? Will apps for WP8 that use only WP7 API work on both? Or is the WP8 APi too different? What would a exactly dev need to do if he wants cross compatibility?

Even if you stick with C# and XAML and use no new hardware features, WP 8 will produce a different binary than WP 7 simply due to the differences in the .NET frameworks. WP 7 runs Windows CE with .NET Compact Framework. WP 8 runs Windows NT with the full .NET framework. The Compact Framework is a subset of regular .NET, so 8 will be able to load 7 apps, but not the other way around. (Try making a .NET project that shares code between WPF, Silverlight and WP7 and you'll see what I mean)