Thanks for a wonderful post! It really helps to have a sense of priorities so that while everything gets done, those things people need most get done first.
Some quick answers to specific questions...
One key feature would create instant MF adoption: enable updates made within MF to contained linked MS8 maps to be persistent. WHY has this functionality been intentionally omitted?
Initially, that's the combined result of Radian being a DBMS tool and Release 8 not having been designed to be driven from an external user interface console through OBDC.
we could enjoy the benefits/strengths of both products until MF evolves into an all-purpose GIS tool (MS9?), supplanting MS8
That's the real and most important task, to reduce the time to 9. As good as 8 is, it has structural limitations from an earlier day that cannot be blended seamlessly into a fully parallel world of Radian, Future and 9. Any Radian-based product has to treat 8 as a limited thing, a sandboxed environment so to speak, where connections to and from have to be translated on the fly from what Radian is capable of to what 8 is capable of. That's a huge amount of effort that takes a lot of time to do, and at the end is somewhat pointless if you really intend to replace 8 with 9.
Much better would be to invest the same effort into getting to 9 faster. In fact, it's quicker to get directly to 9 than to invest into supporting a parallel world running 8, hence the decision to connect to 8 as a source for work in Radian/Future/9 (a quick and easy thing to do) but not to delay 9 with a massive investment in twinning with technology that 9 renders obsolete.
Commenting on the list... keep in mind that it's only been a month and a week since we started moving a "database tool, not a GIS" into becoming a GIS, so a lot of this is in the works.. :-) We're doing the basics in two cycles: first, a turn through vector editing, formatting, selections/transforms/tables, and print layouts at the entry level and then a second turn through all those to backfill stuff left out during the first turn, make adjustments based on community feedback, etc.
(creating bounded areas, registering images of archaic paper maps using control points, navigating a helicopter to a specific sample site using the GPS console, fixing error-ridden imported linework using topology factory, snapping to grid/graticule, drawing freeform lines, and printing maps
... bounded areas are easy. Sounds like that would make a great transform to add.
... registering images using control points. That will come with raster editing. We want to pump out full vector editing capability first and second do the full raster editor thing.
... GPS console. Part of making a GIS from a database tool, I agree.
... Topology factory. This will be done using the new transform pane technology, which has not yet been merged into the system but is one of the big things in the weeks ahead. We're moving such capabilities out of dialogs, like the Transform dialog in the current system, into panes, which provide a much greater degree of interactivity between the map display of the data and the control panels in the panes.
... snaps to grid /graticules. This almost made it into the first cycle of editing, like the snaps to vertices, but instead will be in the second pass. There's a nice variety of snaps that will be in the system.
... drawing freeform lines. Likewise. There will be a variety of editing tools beyond the basic ones now there. We are trying to apply a "less is more" philosophy so instead of dumping a truckload of every possible editing tool imaginable (most of which never get used) to instead present a reasonably rich set of those tools that actually get used.
... printing maps. In this cycle for basic print layouts.
custom line types and the ability to easily apply formatting to areas bounded by those lines (geological contacts).
The former I understand and is coming. Custom styles for areas, lines and points will be there in the next turn of the cycle through formatting. The latter I'm not sure I understand what you mean. If you mean a control that says "format everything that touches anything in this set" it seems to me that is more a selection or SQL thing where you want to organize the relationships between data. Once you have relationships that you want, then a standard, rich set of thematic formatting controls should work great and there should be no need for special-case thematic formatting tools.
The ability of MS8 (and earlier versions) to very efficiently and rapidly create bounded areas from lines and to apply thematic information based upon attributes of a point within the bounded area,
Given a "create bounded areas from lines" function, 9 will do that far more efficiently and faster than 8.
We suspect that MF could benefit from less reliance on polygons which on their own are inherently redundant
Well, nothing about Radian, Future or 9 relies on polygons. At a deep level the system doesn't really care.
But you can't say the same of a legacy infrastructure of zillions of data sets where GIS practitioners for several decades have accumulated exabytes of data where they use polygons to order notions about what is the inside of a system of ordered coordinates and what is an outside. There is so much of that already done and out there that it merits features in the GIS to exploit the data people have and how they have chosen to order it.
as are spatial overly functions.
Lots of them already there, in case they were overlooked.
the MF color reference seems unnecessarily arcane (there is probably some code efficiency reason unknown to us): it would seem that the color values are base 10 equivalents of hexadecimal representations of the RGB values.
I haven't looked explicitly but I suspect this is nothing more than the infinite influence of the web, which to a greater and greater degree defines and rules all aspects of human life. My guess is that whatever trendy JSON web style stuff is now being used for color values is what is driving the Radian choice. The technology of the web for cartography and GIS outweighs what classic GIS people do by about a billion people to one so there is a lot of benefit to piggybacking on whatever they do.
It's a bit humbling to realize that some programmer sitting within Google who can't even spell "GIS" might decide to apply a particular standard to Google's web mapping API and the next day whatever color value representation that guy decides will have a greater influence on what billions of people do in spatial work than the cumulative effect of ESRI hammering away for half a century.
But it is what it is and if you can use what that guy decides to make life easier for users, may as well leverage it.