duplicate routing-key-expression properties with @MessagingGateway

[Xtreme-Light]

Thank you first.
I use Spring Integraion's @MessagingGateway to send message to Spring Cloud Stream,When I used lasted Stream,I got some problem.

I see issue from How to use a SPEL expression that is applied on a POJO for the routingKey

and then I got it ,why I cannot just use @MessagingGateway to send message to spring cloud stream's mq.(before 3.0 We used this way to Send message)
then, I should give each producer bindings the config: producer.routing-key-expression ,although I don't need it。

beacause the code :

				if (environment != null && environment.containsProperty("spring.cloud.stream.rabbit.bindings." + channelName + ".producer.routing-key-expression")) {
					this.setSkipOutputConversionIfNecessary();
					functional = false;
				}
				if (!functional) {
					messageChannel.addInterceptor(new OutboundContentTypeConvertingInterceptor(contentType, this.compositeMessageConverter));
				}

without the properties the SimpleMessageConverter just work with the byte[] string or Serializable。
because we lost the transformer OutboundContentTypeConvertingInterceptor

In office doc
we can see

A better approach to solve this requirement would be to pass the type information as message headers (e.g., application/json;type=foo.bar.Baz ). You’ll get a clear readable String value that could be accessed and evaluated in a year and easy to read SpEL expression
Additionally it is considered very bad practice to use payload for routing decisions, since the payload is considered to be privileged data - data only to be read by its final recipient. Again, using the mail delivery analogy you would not want the mailman to open your envelope and read the contents of the letter to make some delivery decisions. The same concept applies here, especially when it is relatively easy to include such information when generating a Message. It enforces certain level of discipline related to the design of data to be transmitted over the network and which pieces of such data can be considered as public and which are privileged.

so ,I have questions.

1. the bug fix with that issue, cause the conflict with office doc. If spring cloud stream don't suggest that then cannot use spel to route message with payload.I think it is fine.It is not a issue.
2. the bug fix cause some problem，like I said，when I used @MessagingGateway （spring integration）I needed to give each output a unnecessary properties or use Serializable pojo

Thank your work .