What are the use cases of the generic param in CosmosMsg? As far as I can see the message is added to the response of entry points handlers in smart contracts. In wasmd it is translated from CosmosMsg into []sdk.Msg by a default message encoder:

func DefaultEncoders(unpacker codectypes.AnyUnpacker, portSource types.ICS20TransferPortSource) MessageEncoders {
	return MessageEncoders{
		Bank:         EncodeBankMsg,
		Custom:       NoCustomMsg,
		Distribution: EncodeDistributionMsg,
		IBC:          EncodeIBCMsg(portSource),
		IBC2:         EncodeIBCv2Msg,
		Staking:      EncodeStakingMsg,
		Any:          EncodeAnyMsg(unpacker),
		Wasm:         EncodeWasmMsg,
		Gov:          EncodeGovMsg,
	}
}

where NoCustomMsg is defined as:

func NoCustomMsg(_ sdk.AccAddress, _ json.RawMessage) ([]sdk.Msg, error) {
	return nil, errorsmod.Wrap(types.ErrUnknownMsg, "custom variant not supported")
}

So in other words, if a given blockchain developers does not configure otherwise, smart contracts should not return custom types.

Some blockchains may use the custom msg by implementing their own encoder. The problem is that Rust's type system cannot prevent mistakes related to mismatch between the chain's custom type and the one defined in the contracts.

My proposal is to use Custom(Binary) as a custom field. Contract devs experience would change negligibly - they'd need to serialize the custom message before creating CosmosMsg::Custom. We could add a new method for that:

impl CosmosMsg {
    pub fn new_custom<T: Into<Binary>>(msg: T) -> Self {
        Self::Custom(msg.into())
    }
}

PoC: #2475

use Custom(Binary) as a custom field

This approach is reasonable, but it is pretty much what CosmosMsg::Any already does

I think the benefits that CosmosMsg::Custom has over CosmosMsg::Anyare:

• some level of type safety (and chains can provide types for this in their own crates)
• uses JSON, no need to choose a Protobuf library, get protobuf definitions, etc.

With the Custom(Binary) approach, we lose the first one. And in some sense, also the second one because we no longer have any control over the encoding of the data.
This change also seems to be breaking the contract <-> VM interface, i.e. contracts that use the new way don't work on pre-3.0 chains and the other way around. If we want to solve this issue, we can break the contracts on the source level, but not this interface.