what sets microcontrollers apart are bugs, ease of use (both software and hardware) and electrical quality of the design.
Ah. And
Documentation. Some vendors have notably worse documentation than others. FTDI doesn't much document the architecture of their Vinculum2 chip at all. Intel's documentation for their chips (even the supposedly embedded-friendly Quark chips and Curie modules) has been late, hidden behind NDA agreements, or sucky.
For ARM chips, there's a great deal of variation in how many different datasheets you'll need. It's pretty common to have a chip data sheet describing pinouts, a family datasheet documenting how the vendor peripherals work, and a pointer to ARM documentation if you want to know about the ARM peripherals (SysTick, NVIC), instruction set(s), or architecture (that's at least 2 and perhaps 3 ARM manuals to go with your 2 vendor manuals. Fun, eh?)
A couple of vendors/devices I've looked at stand out as having unusually complete single datasheets - the TI Tiva series is one, and the Atmel SAM3X is another (interestingly (?), the Atmel SAMD chips go back to omitting the ARM-side documentation that the SAM3X datasheet includes.)
A lot of this is more relevant to the "moving" part; once you gain some familiarity with an ARM chip or two, you'll have figured it out and it probably won't bother you too much to have a separate ARM TRM document. But when I was first looking at ARM, it was driving me crazy. (and I think the ARM documentation has improved. I could swear that when I was first looking, they has Cortex M documentation that said essentially "This supports the standard ARM v7 instruction set except for all the non-thumb instructions." Now there are distinct manuals !)
This applies to any vendor libraries, too. In general, I think the libraries suck and avoid them, but they CAN be useful examples for understanding how the chip actually works.
IFF they're reasonably documented and the source code is browseable. My current peeve is that I can't figure out how to browse Atmel ASF source unless I add it to a "project" first (possible, but annoying.) ST, IIRC, had a nice library doc/source browser, but it was based on windows .CHM files and therefore not as nice on non-windows systems. A lot of libraries have DOXYGEN-generated documentation that has a description of every individual function, but seem to lack any overall explanation of philosophy, high-level operation, or interdependencies. ("Yes, the
uart_init() function has an argument of
uart_init_params with type
uart_init_parms_t. That's just ... swell. Thanks.") The vendors that have changed their library philosophy a couple of times in the last decade (samlib->ASF->Start, or stmlib->cube->whatever) don't make it any easier (but at least they're DOING something...)
A lot of it seems to be "Everything sucks; I'm just going to bang my head against this arbitrary choice until I understand it, and I hope the second one will be easier."