In C#, you would not be able to use the equivalent of FixedWidthInteger as a type.
C# observes the invariant that any interface used as a type (i.e., existential) must satisfy itself as a constraint (i.e., conform to itself)—as Slava explained—and enforces this at the language level. (This does imply, unless I’m mistaken, that semantic guarantees not expressed in code cannot be enforced.)
Until later versions, C# did not support static abstracts in interfaces (i.e., static requirements without default implementation, such as FixedWidthInteger.bitWidth). When they did, they had to adopt language changes so that interfaces with static abstracts could not be used as a type. As you might expect, users didn’t like having restrictions, but there really wasn’t a choice but to plug that hole.
See this C# proposal for a discussion of a spot they missed with their initial restriction that had to be fixed: Disallow interfaces with static virtual members as type arguments · Issue #5955 · dotnet/csharplang · GitHub
In Swift, we also used to have certain restrictions on which protocols could be used as existential types (the fondly remembered “Self or associatedtype requirements” diagnostic). We decided that it would be better to allow them to be used as types, but not expose the specific functionality that cannot be used, than to prohibit their use as types altogether.