I think developers often lose sight of the fact that the C# type system is not the .NET type system. Instead the C# type system is merely a layer on top of the .NET type system providing both additional capabilities and additional restrictions.
Think most developers if asked would say C# is a super set of the .NET type system. Providing only new capabilities like lambdas, dynamic, pattern matching, etc ...
In reality though we also have restrictions that, while likely well meaning when initially implemented, are leaky abstractions that are pretty easy to poke through once you know the right levers to pull.
The .NET type system allows for several forms of array type punning: int[] <-> uint[] and byte[] <-> sbyte[]. C# though disallows such conversions. Unless you insert an object cast into the middle
uint[] -> int[] // C# error
uint[] -> object -> int[] // okay
uint[] -> int[] // C# error
uint[] -> object -> int[] // okay
The .NET type system represents bool as having one byte of storage and hence 256 values. C# though believes bool to have two values: true and false. Hence there are 254 forms of true that C# doesn't really think are true. This can be demonstrated with explicit layout tricks
The .NET type system also allows for a full range of operations on native sized int, what C# expresses as IntPtr. But C# uses only the operators defined on System.IntPtr which is an insufficient replacement.
Related point. When you're using Blazor you're actually dealing with three type systems: Web assembly, .NET and C#. I'm familiar enough with web assembly to know how to exploit the gaps but I'm confident there is a way :)
