The question is, which RISC-V? You're providing a single kernel for phone-like things, so probably RV64I as a base. MAFD is pretty much required for running a Java VM. Q, no. C, are you shipping for Si-Five or Qualcomm? J/T/P/V would be useful, but does the kernel need it? H is needed for Android phones these days but not watches. S, no idea.
The explanation makes sense to me; let the dust settle and have real hardware shipping before defining the base feature set in a generic kernel image.
There are baseline profiles, like RV23A, that standardize a set of extensions for a class of hardware. Problem right now is that Qualcomm and Si-Five disagree on what extensions should be supported, and there is hardware shipping or in development with two different definitions.
Couldn't Google (who after all does Android) simply declare that the 'official' RV64 is IMAFD (aka 'G') CJQTVPBHLNSUX ? (or whatever makes sense, given the android roadmap). https://en.wikichip.org/wiki/risc-v/standard_extensions
And if they did this, this would prove why Android's parent company is called Alphabet!
There is a standard profile called 'RVA22' and 'RVA23' after that. If you watch the presentations from google on this, they will almost certainty target one of those two standards, very likely RVA23, specially if its now delayed.
Android could also define its own profile, but there probably wont be a reason for why they would need to do this.
It's really not that bad when you consider that RISC-V is built to be used in anything from a tiny mcu to a large server cpu. Compare with the set of extensions to x64, too.
It hasn't actually resulted in that much fragmentation. Android will target the standard profile, they have already announced that. There are standard profiles that pretty much get used by everybody that is trying to make something that runs generic software.
If you have some one of consumer electronic device that runs one specific software, you might not follow a profile, but even then most will follow a specific profile.
The answer seems to be that MAFD refers to the union of the M, A, F, and D extensions to the baseline ISA, adding integer multiplication and division instructions (M), atomic instructions (A), single-precision floating point instructions (F), and double-precision floating point instructions (D).
The explanation makes sense to me; let the dust settle and have real hardware shipping before defining the base feature set in a generic kernel image.