No, CBOR should not replace MessagePack. The CBOR spec was written without the participation of the MessagePack community or the consent of its creator. CBOR added a number of questionable and unpopular features that lacked community consensus such as variable-length arrays and maps, or prefix tags for an arbitrary list of semantic types (URI, mimetype, base64, etc.) It also proposes various levels of strictness and canonicalization such as key sorting of maps based on binary representation. All of this complicates encoding and parsing which runs counter to the goals of a simple binary format.
Wait, since when do you have to have the consent of the creator of one serialization format to create another?
Tagged values are useful! Because of the simplicity of CBOR (compared to MessagePack), it's about 3 lines of code to implement them in the encoder.
I'm not sure I understand your complaint about canonical mode. First of all, it's optional, and secondly, it's actually good that it's defined in the spec, otherwise you'd have multiple incompatible formats like canonical JSON.
Of course they don't need consent. The point is that standardization is meaningless without the support and participation of implementers and users. This is why CBOR has made no progress in replacing MessagePack.
The point about strictness and canonical mode are that they are poorly thought out. For example, sorting based on binary representation requires multi-pass encoding which is slow, complex, error prone, and completely non-intuitive: [1,2,3] comes before 100000 which comes before [1,2,3,4].
