You raise so many good points, in good faith, let me try to address them. This is not intended in any tit for tat way but rather to try to open up the discussion to perhaps show that what you want is there before you.
It is there in a different way, of course, which is the usual learning of new and improved methods which open the door to greater capability. Zipping about in a sports car really is faster and covers more ground than trotting on a horse. But as much fun as trotting on a horse may be, the skills which enable one with confidence to cover ground on a horse are fundamentally different than those required to drive, say, from San Francisco to Ensenada in a day, covering huge mileage on Interstate 5 and successfully punching through LA traffic en route.
I use Manifold to keep track of parcel ownership in a mapping environment - not as a tool to learn SQL.
That is a bit like saying "I use my sports car to get from San Francisco to Ensenada, not as a tool to learn how to work the steering wheel, the gas pedal and the brakes." Well, sure. Likewise you use Future as a tool to get tasks done, not to learn SQL. For that matter, you con't need to know SQL to drive Future, no more than you need to know how to work a clutch and manual shifter to drive a car with automatic transmission.
Future has automatic transmission. No need for SQL, for most things, if you don't want it. But just like you can find endless examples of tasks in 8 that require SQL (8 has nice SQL, not as nice as Future, but still very cool...), just so for Future.
There is a huge amount of work you can do in Future without knowing a drop of SQL, just by using things like the Select and Transform panels. As more and more templates are added there will be even more capabilities that don't require any SQL. So positioning the matter as 8 being SQL-free while Future requires SQL is totally wrong and misleading. If you think that way you are denying yourself the use of a hugely powerful tool that in most (not all, but most) respects is much easier to use than 8. A good example of that is previews. You don't get any previews in 8 but you do with Future, which really helps avoid making mistakes and also helps zeroing in on doing exactly what you want to do.
But beyond all that if you want to learn SQL to lift your game to much higher capabilities, to do work more effectively and faster and with less effort, well sure, it is truly great and wonderful to spend the utterly trivial amount of time required to get going with SQL. That's true for 8, and it is also true for Future. That Future has far stronger SQL than 8 is a good thing, not a bad thing, because it enables you to do far stronger things with SQL in Future than you could do with SQL in 8. All that is very good, and is not remotely any sort of a flaw. It is genuine progress.
I have never met anyone who has sat down with, say, one of Chris Fehily's books and then spent a solid few hours learning SQL from the beginning who did not say, "wow... this is really all very easy. I don't know what the fuss was about..." Anybody smart enough to be doing GIS at all, at any level, is more than smart enough to realize from such an experience that starting with simple use of SQL is just a beginning, and right away will see that you can add to it to make it as complex and elaborate as you like. Or not.
But I have met zillions of guys who never sat down to learn SQL from easy, simple basics who complain how hard it is on the basis of thrashing around poking at buttons and trying to figure out what is going on from master class examples like those Adam or Tim contribute to this forum. For lack of investing a couple of hours up front to start learning the thing properly from the beginning they'll spend a lifetime encountering frustration and complaining.
Now, it could be that you are the one guy, the one exception in hundreds, who has sat down for some quality time with a Fehily book, and yet despite spending a few hours or a day or whatever learning the very basics, still thinks
SELECT name, address, city FROM clients WHERE city = 'London';
is so totally complex it could not be understood by ordinary mortals. But I'd bet not. You don't need SQL at all to use Future and to do wonderful things.
But if you make the trivial effort to learn the world's most widely used means of interacting with data you can do even more. And not just with Future but with a few thousand other packages. Nothing wrong with that!
In 8 it needed no separate query. I could relate tables as fast as I could click and get all the fields from each one. With 9 each table needs a custom query which is not intuitively obvious to a SQL plebe like me.
You could relate tables as fast as you could click in 8 because you had taken the time to learn how to do that. Beginners cannot relate tables as fast as they can be clicked in 8. It turns out you can relate tables even faster in 9 with even fewer clicks, (double-clicks, actually) to add tables using the query builder. It's not obvious to you because you've not yet learned how to do it. Once you do, you'll see it is even easier than in 8 while being far more flexible, far more powerful and much easier to maintain or to alter to adapt to changing interests.
Those toolbars are always on at the bottom of the window, so I don't have to think about the process for finding the Transform pane.
"Process for finding?" ... over the top given the zero effort of clicking Transform in an always-present, always responsive Contents pane. That's like complaining about the "process for finding" the kitchen in your own home. :-)
Secondly they automatically switch modes depending on whether a table or map is in focus.
Same with the Select and Transform panes.
Third, most of the references in the Transform menu are understandable. In 9 it is often very cryptic (e.g. Parse GeoJSON, bounds, branch, Compose Point, copy (but no paste), etc.)).
There's no "Paste" in the transform toolbar in 8. Many of the transforms have the same names. Some don't because they are different. For example, 8 has no ability to parse GeoJSON. If you work with GeoJSON you know what that means and you are happy to have that capability.
I think 8 has reasonable names for templates but I respectfully disagree that names such as "Span Excluding" or "Decompose to Convex Parts" are automatically self-documenting for people who don't RTFM. You have to read the fine manual to understand what they do, and then beyond that you need some experience and familiarity with them before they start sounding obvious. Same with new Radian templates.
Some of those, by the way, have different names from 8 analogs because Radian tends to be more precise than 8. A word like "bounds" is slightly more precise than "boundaries," for example, in that "boundaries" tends to imply internal dimension that only areas have while "bounds" tends to cover "extremities" or "markers" in a way that slightly (just slightly) is a better fit to the end points of lines or the single coordinate location of points. It's not like after a moment you wouldn't immediately recognize Bounds in the list of templates for what you used Boundaries in 8.
It would be better to address the very long list of possible templates and how they can be handled. Future has yet to add all the various token operators, for example, and one reason is that you end up with very long lists (even longer than the long lists in 8) of templates that can be cumbersome.
I can't imagine how many lines of SQL (that I don't have to learn) are buried in the 8 toolbars, and I appreciate it.
Same with Future. You have hundreds of templates with not a single line of SQL you need to learn to use them. But, unlike 8, if you want to take your game to the next level Future will show you the SQL behind each template so you can modify it to suit variations or to learn.
What is the motivation to change every aspect of a program that is just the next version?
If Future were just the next version of 8, I'd agree with you. Future isn't the next version of 8. It is a completely new and different product. It does far more than 8 with endless detail in greater accuracy, rigor, sophistication, flexibility, capacity and more. Pretty much any new technology is like that: your smartphone has basically every aspect different from a rotary dial landline telephone. Zipping around on a jet ski is very different than paddling a canoe. Flying a jet with a glass panel requires significantly different cockpit design than flying a biplane.
Sometimes when technology changes vendors will try to package new things in old wrappers to ease the transition. The very first automobiles, for example, were modeled on horse carriages. Until it became clear that to really take advantage of the new technology and to provide an even higher level of comfort, ease of use, and convenience it was better to design automobiles to be automobiles and not powered horse carriages.
My challenge to you is to learn the new environment so you can take advantage of the power and convenience it delivers. Then, if you find something lacking or inefficient, say what it is so it can be improved. But stuff like this...
but I don't like the inability to use mouse and kbd combinations to deselect
... is not helpful because it is so untrue you may as well be talking about Excel and not Future.
Deselect? Trivial: If you like keyboard stuff, use Shift-Ctrl-A (a quasi-standard Windows thing) or Ctrl-A Ctrl-I. Deselect with a mouse? That's what the Shift modifier is for. See the video.
Any place where Future is not more effective than 8 is fair game for complaint and improvement. But let's keep such observations to real things and not complain about things which are not at all about Future.
Keep in mind as well that by using Future you are participating in an open beta program, so you should cut the documentation a bit of slack for being behind a very rapidly moving thing. The RTFM effort is harder with betas because you have to cruise on the basis of release notes and introductory videos as well as more finely worked documentation typical of a finished Manifold product. But that's part of the deal for getting access to the hottest technology right away and being able to influence where it goes.
Last but not least, to make useful comparisons such as "A is a much better approach than B" you really have to know both A and B. If somebody recommends A because that's what they know and to learn anything about B requires some effort, well, as far as that goes it is a fair comment but it is not the same as being able to say that A as a way of working is better than B as a way of working.
The comments you make about relations in 8 being so much easier than SQL seem to me to be an example of that. What you are really saying is that what you know how to do in 8 is much easier than something which you have not learned. Well, OK, I'll agree with that as far as it goes, but it doesn't go any farther than announcing that something which has not been learned cannot help you. It doesn't touch the idea that once you learn a bit of SQL you can do what you want to do with far greater ease, more power and greater flexibility than using relations in 8.
And that's really the idea for which Manifold is created, to provide greater ease, more power and greater flexibility, all for less cost. You do have to learn to use it, but hey, that's to be expected for any worthwhile new thing, whether it is carpentry, learning to drive a car or even learning to ride a bicycle.