In practice this functionality is rusted in place. If you invented a new name type, that doesn't mean you can call your existing TLS stack's SNI methods with "@Twitter_handle" or "[email protected]" or "#TopicGoesHere" because those methods always write DNS names. There is a type parameter, there has only ever been one type (DNS names) and so that's what your implementation chooses and I haven't ever seen one that lets you change it, because what would you change it to?

You don't have to invent a new name type.

RFC 5280:

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions.

X509's subject alternative name extension has nothing to do with TLS' SNI extension. SNI does not have a mechanism for locally-defined name types akin to X509's OtherName.

SNI matches certificates by looking at the SAN list on a list of certificates and finding the best match.