Rationale

Imagine you have an arm64 CPU with ArmBase and ArmBase.Arm64 support (both are always enabled for any arm64 CPU), but without Aes, Sha1 and Sha256 features, let's run the following snippet:

Console.WriteLine(ArmBase.IsSupported);       // true
Console.WriteLine(ArmBase.Arm64.IsSupported); // true

Console.WriteLine(Aes.IsSupported);           // false
Console.WriteLine(Aes.Arm64.IsSupported);     // true (??)

Console.WriteLine(Sha1.IsSupported);          // false
Console.WriteLine(Sha1.Arm64.IsSupported);    // true (??)

Console.WriteLine(Sha256.IsSupported);        // false
Console.WriteLine(Sha256.Arm64.IsSupported);  // true (??)

The problem here is the fact that Aes, Sha1 and Sha256 inherit from ArmBase but don't define their own Arm64 nested classes, see sharplab.io for more details (it explains why it can't be fixed in the jit).

Proposed API

    [Intrinsic]
    [CLSCompliant(false)]
    public abstract class Sha1 : ArmBase
    {
        internal Sha1() { }

        public static new bool IsSupported { get => IsSupported; }
        
+       public abstract class Arm64 : ArmBase.Arm64;
+       {
+           public static new bool IsSupported => Sha1.IsSupported; // && IntPtr.Size == 8 ?
+       }

(same for Sha256 and Aes)
UPD same for Aes, Avx, Avx2, Fma, Pclmulqdq, Sse3, Ssse3

/cc @tannergooding @echesakovMSFT