Package reflect has to do some extra work to dynamically build slices of exported methods for types, but it looks like this could be handled at compile-time by simply statically partitioning exported and unexported methods, and then using the unused uint16 field in runtime.uncommontype for the boundary.

This could potentially cause problems for any code that iterates over method sets and expects a particular ordering. I looked over the interface-implements logic in runtime and reflect at least, and they appear to be insensitive to the particular method ordering as long as its consistent.

Notably, sorting exported methods before unexported methods is identical to the status quo when names start with an ASCII character, which is the common case in the standard repo. This could cause ordering assumptions to go unnoticed, so maybe it's preferable to do the opposite (i.e., unexported methods first).

Related #22073.