Since we can expect GUIDs to come in various formats, I agree with making the deserialization somewhat flexible.
However, in the implementation, please be careful about unnecessary allocations.
Also, it's important to consider whether the approach is properly generalized.
If specialized handling is needed, I recommend preparing a separate formatter and combining it with the resolver.

However, in the implementation, please be careful about unnecessary allocations.

Fixed that

Also, it's important to consider whether the approach is properly generalized.

What does this mean? If many message pack serializeres serialize uuid as 16 byte big endian values?

If specialized handling is needed, I recommend preparing a separate formatter and combining it with the resolver.

I'm doing that now, but it felt such a common thing that I didn't expect that binary uuids were not supported. I didn't verify other runtimes/packages.

As you can see there is significant size savings. Imaging a type that has a few uuid properties. That is 20 byte per uuid.

@neuecc I also noticed this:

NativeGuidFormatter:

https://github.com/MessagePack-CSharp/MessagePack-CSharp/blob/v3.1.3/src/MessagePack/Formatters/UnsafeBinaryFormatters.cs

A remark on that type is the implementation only works on LITTLE endian environments.

Would it be ok to refactor this PR into a newNetworkOrderUuidFormatter that (de)serializes to a big endian 16 byte uuid? I think that makes sense.

Would it be ok to refactor this PR into a new NetworkOrderUuidFormatter that (de)serializes to a big endian 16 byte uuid

seems good.