That one, oh-so-minor difference is a thorn in many a uC experimenter's side, because it means that standard 0.1" spacing of pins to make custom shields is impossible without special thru-pin headers, bending pins, third-party thru-hold blank shields, or just leaving one or the other header off entirely (which isn't a real solution if you need one or more pins on both headers).
We could have seen a ton of custom 0.1" proto and strip-board shield designs, but instead we are thwarted by this one simple mistake caused by being in a hurry due to a deadline.
Now - we are stuck with it - likely forever, because each new iteration of microcontroller hardware almost guarantees that there will be support for "Arduino Shields" because so many are out there. Yes, I know there are experimenters "blank" shields - but they are rarely as inexpensive as a standard 0.1" PTH PCB - and almost all of them are the size of a single shield, none larger.
It would have been nice, for instance, to be able to put in extra-long pin headers on an Arduino, then plug that on top of another larger PCB with standard hole spacing (whether soldered in-place or via headers too). Instead, the only option is to "build" the Arduino onto such a custom board (ie, program an ATMega328P and plop it on the board with resonator/crystal/power/etc).
/sigh/ - oh what could have been...!
Plus there are many versions out there within the arduino ecosystem, including larger pin count ones, faster processors, and even ones that use non-Atmel chips like the Teensy.
There was a problem, and It's been solved.
While I agree that the ecosystem has provided solutions, I would have to respectfully disagree with your conclusions.
Had the problem been solved, we would not see new SoC and microcontroller platforms (heck, I think there's even an FPGA dev platform out there too) that continue to supply properly-spaced headers for this issue.
Doing so continues to perpetuate the problem, not solve it, in my opinion. A real solution would be to fix the issue (ideally, by the Arduino team), and there being a push to adopt the new layout/spacing. Perhaps an adaptor shield could be created, too, for legacy support.
Honestly, this should have happened immediately after it was found to be an issue (which likely would have been seen a long time ago with the early ATMega8 RS-232 boards made for the educational classes or whatever Massimo made the boards for originally); it should have been corrected there and then, with the next iteration.
But, history is history, and there's nothing we can do but lament, learn, and move onward...
It works as advertised, the PCB is beautiful, and it's significantly less proprietary than any board I've used before. All in all, well done.
That being said, I'm puzzled by the low amount of SRAM. I'd expect a chip that runs at a couple 100's of MHz to come with 64-128KiB.
But AFAICT flash memory is an area full of patents and secret sauce. I'm not sure what's involved but it would be nice if some open flash designs become available soon.
Currently "open source IC's" extend to the HDL piece only - embedded flash in 130nm is a highly complicated piece of IP and is either available by third party or through the foundry under license. I am assuming the SRAM physical IP (16KB) in this chip is also a propriety library as well.
Having recently been through building a not dissimilar IC I rushed to be first in line to pick up one of the founders HiFive1 boards (its a great board - really tidy) - this project is a huge step in the right direction. Consider this alternative - in trying to figure out some complicated ARM Cortex-M bug recently, the final solution was found by 'a friend sourcing some information from China'; this is for IP that we'd paid for (although not enough!). ARM are not bad at support at all, but we are very small and help doesn't often come to those who need it in this situations, but those who find it. I'd much rather have an IC with all the digital pieces available and an open community of people integrating it into various projects when trying to make my own project succeed.
Presumably they just didn't want to devote engineering time to something nonessential for the first project.
On side of riskier ones, there was Plasma MIPS and Amber ARM that might have been turned into ASIC's. Less risky, but less supported, OpenRISC was turned into one. RISC-V is best contender right now far as most openness and industry support. Great there's boards with some of them. Leon is still ahead in terms of features & performance on something you can actually buy. I still think someone should try converting the Leon3 + libraries to a RISC-V to get its I.P. as a starter pack.
What? To me this reads like: "Here's a pink unicorn! If you argue it's a brown horse with a cardboard corn I dare you to show me a horse that is more unicorn!". Is it open source or not?
Open Source (software) equivalent would be something like a Linux distribution that is generally fully open source but relies on a binary blob driver for the videocard... Is it still "open source"? Yes, mostly, but not 100% fully.
Followed up with the best attempt at a pickup line by a hacker in the movies. Back before the movies had them making out with random women in bathrooms over job offers involving sex, alcohol, bombs, and Houdini tributes. Hackers got really cool really fast. ;)