The feature would provide a way to ABI-encode a function call with abi.encodeWithSelector() by calling a helper method on that function.
So for example C.foo.encode(x, y, z) would return a bytes array containing an encoded representation of a function call with selector C.foo.selector and values of x, y and z encoded as parameters according to the function signature. Unlike abi.encodeWithSelector(), it could ensure that the representation actually contains a function selector, and that it has the right number of arguments and the right argument types.
Definitely yes. It seems to be way more clear, simple and less faulty way to encode a method call. I’m sure it should be named in some more behavior-specific and less general name, like encodeCall or encodeAbi.
For cross-chain applications sending messages through messaging bridges requires passing around raw abi encoded bytes. This leads to ugly and unsafe code that uses a lot of abi.encodeWithSelector. This feature would eliminate a lot of this risk and hassle.
Also useful for interacting with mock accounts that forward arbitrary arbitrary bytes calls (like you might use with DappTools!)
The type-safe encoding is not the only important element here though, the sugar of being able to just chain .encode to any function is important for making this accessible for devs. Using something like abi.encodeCall for this is unnecessarily off-putting and should be avoided imo.