This change could be controversial: both keeping old name and strictly following the spec's name makes sense. Even Linux doesn't strictly follow spec's field name such as PARTITION (PART) and DEVICE ('CARD`), so handling these cases in linuxkpi header is inevitable either way. I want to hear others' opinion on this.

As this moves MMC 3.31 to eMMC 5.1, we need to discuss backward-compatibility issue.

In fact, the macros added as part of implementing eMMC support already
were based on v5.1 of the eMMC specification. However, some have been
shortened on purpose in order to make it easier for keeping resulting
code within 80 columns.
Apparently, Linux chose to do the same and as you say, still as of today
uses e. g. EXT_CSD_CARD_TYPE and EXT_CSD_PART_CONFIG. Thus,
it seems backwards to change such macros to something Linux doesn't
use either.
Moreover, with 49 chars EXT_CSD_NUMBER_OF_FW_SECTORS_CORRECTLY_PROGRAMMED
is ridiculously long and Linux apparently doesn't have a macro for that
register at all.
Thus, overall, I'd prefer to stick to the convention of shortening macro
names where it makes sense (also for additional ones being added), and to
just add alias macros to linuxkpi when needed.
Generally, your patch also mixes the addition of new macros for mostly
SPI mode with changing existing ones, which should be separate changes,
if at all.

The more controversial point is what SDIO support in linuxkpi will be
based on. Hopefully, that won't be the failed academic experiment known
as MMCCAM. Given that the successor technology (see ufshci(4)) is already
15 years old by now, I'd rather import the known-working Net/OpenBSD
SDIO code and be done with it instead of having to port lots of existing stuff
over to MMCCAM. Net/OpenBSD also already even have a driver for the
WiFi on Raspberry Pi.
As such, MMCCAM feels like reimplementing isa(4) on top of CAM. Now
there _might_ have been a point for going the CAM route iff MMCCAM
supported CQE right from the beginning. However, as it currently stands,
MMCCAM doesn't even have feature parity with mmc(4)/mmcsd(4).