1. It's not clear what you're referring to by "multi-field support", but if it's something that's only available in the 3.x branch of CCK for Drupal 6, note that that branch is not stable anyway (only has an alpha release and should not be used on production sites). The 2.x branch is the one that's stable.
Perhaps you're talking about http://drupal.org/node/695636, in which case you'll see that the new Field API allows that feature to be implemented in a much cleaner way in Drupal 7, and there's already a contributed module for Drupal 7 being worked on to do it (which only has a beta release itself, but appears on the surface to be further along than the equivalent Drupal 6 CCK code).
2. Your comment about the database API is incorrect. Simple one-line select queries do not need to use the new OO syntax (and in fact, should not). See http://drupal.org/node/310072.
As for queries that do need it, it seems like you've missed the point; it's not "added complexity with no win attached", but rather the purpose is to support things like cross-database compatibility and access control. Sure, it was simpler in Drupal 6, as long as you didn't mind that your code might not work at all on certain websites :) If you're writing custom (site-specific) code for Drupal 7 and still don't care about that, you can likely use the simpler syntax for more things than it is intended for (although it's obviously still not recommended).
CCK 3's stability isn't the issue here. Given the module maintainer's track record nobody in the community doubts that 3.x would have reached maturity. That development effort was halted when it was announced that Fields API was going in core. In the mean time you still can't sync multiple instances of multiple fields using pure Fields API, not to mention the huge number of field types entirely unrepresented in the core implementation.
So again, we have traded 30 extra sections of time spent on an initial site installation for a feature locked partial implementation that cannot change for at least the next 3 years. Even if the implementation was complete, given how quickly the web changes I don't think any of us can confidently say that it will be well positioned to meet the needs of the day 3 years from now and now that it's in core, it cannot grow between major number releases, which is really what this is all about.
My statement about the database is not incorrect, but I recognize that it's an unpopular position. I am well aware of the stated design goal of the new API. The problem remains that core devs have troweled a ridiculous amount of additional complexity into core to satisfy a small contingent of potential enterprise users that are hell-bent on running MSSQL or Oracle.
I recognize the tradeoff here. On the one hand you have ease of use. On the other you have huge stacks of enterprise client cash. I don't think anyone's confused about which way Acquia went on this one.
I'm an Acquia Project Manager that started working with Drupal in a company that I owned and was one of the PM's for the drupal.org redesign.
2 quick things...
First, I'm struggling with relating Acquia to the MSSQL and Oracle work that was done with the new API. Didn't that come out of AF83 / CG getting a significant amount of investment from Microsoft? Hasn't the decision to put it into core led to a lot of really good conversations and partnerships with other technology providers including everything from additional funding for contributed modules, core, drupal.org features and other things? To be sure, it's easier to develop for just one DB, but it creates a choke-point for adoption that has the potential to stifle a lot of really good things that come out of it. While Acquia has supported the new API, I think it's a stretch to say that Acquia went for the cash as I think we've only done one or two projects of any significance that were not based in MySQL. I've heard of several other projects, and even some really big ones, but they're all at other shops. Singling out Acquia is a clear case of misperception here, and I think if you're going to bash, you should do so fairly.
Second, what's wrong with developing in a direction because you're being paid for it? SOMEONE needs to make money off this, and contributions like the ones your pointing out are both significant shifts in what a group of invested organizations, developers, peers, and business-types decided was the right way to go. The sell-out argument is weak - nobody is running a charity because there are too many of us that have to have jobs so we can pay for things. I agree that the endless pursuit of revenue is not the only thing that matters, but I struggle to see where our (both Drupal's and Acquia's) purpose has become unmoored from our profit motive. The new DB system, fields in core, overlay, and the myriad of other D7 changes are big. There are sacrifices. However, they will continue to improve as more development work gets done and we'll see significant incremental improvements in what many smart, dedicated, and yes... even non-Acquia people agree is the right direction.
tl;dr: Don't piss in my pocket and tell me it's raining.
I understand what you're getting at but I've been with the project since 4.7, and I feel like the time for happy-fun-time talk has passed. Like most community developers, I supported the overwhelming majority of the changes that went into D7 when they where being discussed among the community. Now faced with the reality of D7, I see that some (maybe most) of these additions where a mistake.
Assuming Dries' keynote wasn't based on random numbers, Drupal had reached the "1% of total websites" threshold well before D7 was released. There was no choke point. Look at the following web server statistics http://greatstatistics.com/
MSSQL support doesn't service the majority of potential consumers of a CMS, just a small minority of potentially well-heeled clients that run Microsoft-based environments.
It's counter-intuitive but I've come to realize that sucking module functionality into core is stupid. Example: your choice of forum, aggregator, or blog. All crusty, useless modules that any serious implementation will either ignore, patch heavily with additional contributed modules, or just go with a fully contrib alternative. Why do these modules all suck? They've been stuck in core and thus cannot change. When a major release is planned everyone's busy focusing on the shiny new stuff to cram into core and modules like this are typically neglected. Why should the fields API be any different, given the track record of the last five years?
Also, you may not want to lose sight of the fact that it makes Drupal shops (you know, the little guys who are busily engaged with growing and maintaining Drupal's adoption base) look bad in front of clients when they've been on the receiving end of Acquia-sponsored D7 marketing blasts, meanwhile we're waving them off from migrating because core isn't stable and critical contrib modules are either unstable (RC$n or beta) or entirely non-existent in D7.
I know several contrib module developers that have thrown their hands up in disgust and gone on to work with other communities while new developers are struggling with the unprecedented complexity in D7.
I agree, the changes are big. Some of them are awesome (new menu structure, new AJAX api). Others range from obnoxious and/or useless (overlay) to actively harmful (see also core bug queue explosion). There was a large and VERY vocal contingent among the community that was calling for smallcore years before D7 shipped and a blind eye was turned by a vanishingly small yet disproportionately powerful minority, and now it's biting everyone who isn't vying to become a Microsoft Enterprise Partner in the ass.
And that is my take on the Drupal community as it stands currently. You don't have to agree with me but it would be a mistake on your part to assume I'm an outlier.
Er, your accusations about Acquia here are both incorrect and offensive.
For the record, Acquia was only marginally involved in getting the new database API into Drupal 7 in the first place (probably 95% or more of the work and technical direction for this particular feature was contributed by non-Acquians). Also, given that we (Acquia) own a MySQL-based Drupal website hosting business (and don't really have MSSQL or Oracle expertise on staff so it's certainly not our preference to have clients who want to run Drupal on those systems), the implication that this was some kind of Acquia-directed conspiracy really makes no sense.
Also, the primary motivation of the new database API was certainly not to support these proprietary database systems anyway. Other databases whose code is free (especially SQLite, which is now supported directly in Drupal 7 core) are much more important. And cross-database support is definitely not the only useful feature of the new database API, just one of them. I would suggest reading e.g. http://www.garfieldtech.com/blog/database-tng-lands for more information.
Regarding CCK, it's hard to understand why you are so concerned about features being "locked" in Drupal core for the next few years? For one thing, they're not locked (certain features might still be added to Drupal 7 if they don't change things in a way that will break existing code), but more important, the entire way Drupal works is that core functionality can easily be extended by contrib modules to meet additional needs. As described in the link I provided earlier, the functionality you're looking for is apparently being implemented by the Field Collection module in Drupal 7 (and due to the Field API, it's being done in a way that knowledgeable people seem to agree is much better than any implementation that would be possible with CCK in Drupal 6). So it's not really clear why are you are apparently comfortable typing "drush dl cck" to install CCK for Drupal 6, but not comfortable typing "drush dl field_collection" to install this (or other) modules you might need for Drupal 7.
That is not useful information. It only indicates that someone with package commit privileges decided to package Drupal 6 for Ubuntu 11.10. It doesn't mean anything about usage, developers, community, etc.
To put this into perspective, Debian once had a Webmin package in the distant past (about 10 years ago)...at a time when we had far less than a million new downloads per year (might have even been in the low hundreds of thousands). We're currently at about 3 million new downloads a year, and growing every year, and there is no Ubuntu or Fedora package for Webmin.
All you can assert based on a lack of packages in the standard OS repo is that there is a lack of packages in the standard OS repo.
Well considering that there are about 12,000 projects hosted on Drupal.org and that it has it's own packaging system this is a pretty pointless example. I've never met anyone using apt to install PHP applications. Given the ways that apt usually installs a PHP app, I'm not really surprised either.
Perhaps you're talking about http://drupal.org/node/695636, in which case you'll see that the new Field API allows that feature to be implemented in a much cleaner way in Drupal 7, and there's already a contributed module for Drupal 7 being worked on to do it (which only has a beta release itself, but appears on the surface to be further along than the equivalent Drupal 6 CCK code).
2. Your comment about the database API is incorrect. Simple one-line select queries do not need to use the new OO syntax (and in fact, should not). See http://drupal.org/node/310072.
As for queries that do need it, it seems like you've missed the point; it's not "added complexity with no win attached", but rather the purpose is to support things like cross-database compatibility and access control. Sure, it was simpler in Drupal 6, as long as you didn't mind that your code might not work at all on certain websites :) If you're writing custom (site-specific) code for Drupal 7 and still don't care about that, you can likely use the simpler syntax for more things than it is intended for (although it's obviously still not recommended).