More robust Mega baseline

Is any manufacturer/the Arduino team looking at seamless inclusion of the most commonly used features into a Super-Mega? I'm thinking:

• Seamless WiFi. The ESP8266 has been added to a Mega but it's clumsy - DIP switches are used to change configurations. The IDE should be able to update all portions of the system by directing the sketch upload to the appropriate subsystem without manual intervention. Should the ESP32 or some other solution be used instead of ESP8266? Or, simply WiFi integrated into the central processor.
• CH340 integration. Shouldn't CH340 support be built-in to the IDE by now without users having to download a separate driver?
• MicroSD-based filesystem integrated into the baseline Mega card.
• Micro USB. It's time to get rid of the clunky USB connector.

These features are probably the most commonly needed once the developer's ambitions go beyond intermediate projects.

Projects are do-able by tacking on individual components and manually performing tasks; I'm suggesting that the MOST commonly needed features for projects would be marketable if a more seamless solution were provided.

I realize a seamless integrated Super-Mega card would be a little more expensive to purchase, but purchasing the individual components and the time spent integrating them is more expensive.

The benefit? Users could spend less time with initial project setup and more time diving right into the solution they're trying to implement.

CH340 integration. Shouldn't CH340 support be built-in to the IDE by now ... ?

Why? There are no Arduino products that use a CH340 chip. (There weren't even any from Arduino.org.)

As for WiFi and SD - the ATmega2560 only has a single SPI interface, and it's already "assigned." You can use the USARTs as SPI interfaces, but they're already assigned to pins as well. You can't just use random pins to connect another couple of SPI devices, and using pins that already are connected to Digital IO is pretty fraught with peril.
And while the full-sized USB connector is "clunky", the micro-USB connectors are too often "fragile." (sigh.)
In general, "alternative" vendors don't seem to be very interested in the "Mega" form factor. I'm not sure why. I'd rather see a Mega board based on the new SAMD51 processors - they seem to do everything by 5V IO. Alas, Adafruit (who is leading the D51 efforts) has said they don't have a "big" board on their dashboard... (nor do they have any other Mega-sized boards.)

Maybe I'm not referencing the CH340 correctly. The CH340 I'm referring to is the clone USB interface that Chinese-produced boards use so that they don't have to pay royalties for use of the original USB interface chip. The 16-pin DIP CH340 chip sits right behind the USB connector (see attached picture). Users of these chips have to download a separate CH340-compatible driver.

As for WiFi and SD - I'm thinking of a more tightly integrated solution that would not have to consume SPI, USARTs or Digital IOs. This probably means no off-the-shelf processor could be used. It would probably require a new processor that was developed with integration of these two key features in mind from the start rather than provision for them being tacked-on later.

Yes, the miniature components on our increasingly miniature devices can sometimes be fragile. However, I tend to blame the "old-fashioned" large molded plastic connector bodies and relatively thick wires and insulators relative to the size of our now smaller electronic components. These rather "husky" interfaces to our devices make it easy to incur handling damage. Occasionally I can find slimmer/thinner versions that are easier on our miniature devices.

The CH340 I'm referring to is the clone USB interface that Chinese-produced boards use so that they don't have to pay royalties for use of the original USB interface chip.

I'm don't think that "royalties" are involved. The original code is all open source with royalty-free licenses.
The CH340 is simply far cheaper, and bypasses the need for a vendor to have their own USB Vendor ID. Other clones have been made using both the original and newer FTDI chips, CP2102 chips, even PL2303 chips, for similar reasons.
The question remains: "why would Arduino want to make it easier to use someone else's board?"
A "real" SD card interface ("more integrated" or faster than the one-bit SPI interface usually used for Arduino-like boards) requires memership in the SD association and yearly "dues"; the interface is proprietary and not documented except under NDA (after you pay the dues, I guess!) https://forums.adafruit.com/viewtopic.php?f=63&t=137956 is one discussion. Adafruit has been putting "moderate amounts" (~2Mbyte) of QSPI flash on their SAMD boards as a sort of compromise...
(I guess MKR-Zero has on-board SD card, so there is precedent...)
(So does the teensy 3.6, which could at least theoretically make use of a larger board. 62 IO pins...)

It would probably require a new processor

That's a substantially different kettle of fish. How much are you willing to pay?
("I'll wait for the $10 clones from China" is not a good answer!)

And you still can't buy CH340 in the US from the distributors - Digikey, Mouser, Arrow, Avnet, Newark. Who would design in a chip you can't buy?

I can speak about the "real" SD card interface, which exists on Teensy 3.5 & 3.6. I'm the guy who makes Teensy...

The most important point is you need to transfer large blocks (eg, 4096 bytes) and implement a caching layer with a substantial amount of RAM (for a microcontroller) to really reap the benefit from the native SD interface.

On Teensy, we ship a modified SD library where SD.begin(BUILTIN_SDCARD) tells the library to access the card using the native 4 bit SD interface, rather than using SPI with a chip select pin. It defaults to 4 bits at 24 MHz, and if you edit the code you can enable 4 bit 48 MHz mode. On Teensy, SPI to the SD card uses 24 MHz, but obviously only 1 bit instead of 4.

Using only the SD library, 4 bit SD is faster than SPI, but not anywhere near 4X faster even if you run it at 48 MHz. Usually the speedup is around 50% to 75%, a far cry from 400%. The problem is these cards have substantial command latency and tremendous internal overhead if you write less than the native block size of the card (which can be huge on modern cards). When you have a system like Linux running on a PC or Raspberry Pi with a gigabyte of RAM, dedicating many megabytes of RAM for reading and writing large blocks is "easy". But on a microcontroller with only 8K to 512K of RAM, allocating a big table of 4K blocks and merging writes to a 32K or 64K native block size of the card quickly burns up too much memory.

Bill Greiman has done some excellent work to support these fast 4 bit native SD features in his SdFat library. But it's not simple to use. If you want to get a taste for the incredible performance, Bill's library is free and it runs very well on Teensy 3.5 & 3.6. Last time I looked, he didn't have a caching layer and everything done very automatically, as you get with Linux. It requires a lot of work to manage huge buffers and interact with the card in ways that involve a lot more thought than simply writing data to the card (as you do with the regular SD library, and userspace programs on Linux).

It's easy to get caught up in talking about nondisclosure agreements and the SD association's exorbitant membership fees. But the truth is the "simplified" specs have nearly all the needed info, at least up to version 2 (which allows 4 bits at 50 MHz). Bill's SdFat library and my hacks to the SD library (which are partly based on some sample code NXP published) should be proof enough that using 4 bit mode really is feasible. I didn't sign any NDA or pay anything to the SD association, and I'm pretty sure Bill didn't either.

Now SD version 3 & 4 are another matter. Info about how to really use 4 bit DDR at 100+ MHz mode and switch from 3.3V to 1.8V might be "out there", but I haven't been able to find it. Today very few microcontrollers with native 4 bit SD support more than version 2. Perhaps in the future we'll have microcontrollers with GHz clock speeds and SD ports capable of these speeds? But when/if such hardware becomes available, the main limitation will be the software side. The small memory, no-caching-layer, single-sector-at-a-time approach of the SD library is already inadequate for the 4 bit SD ports microcontrollers have today.

Thanks for the clarification. Not having access to the specs for any "advanced" SPI modes also means I have no idea exactly what those specs are, how many additional speedup "steps" exist, or whatever...
(actually, I wasn't even aware that the 4bit mode was available without licensing...)