The StreamConfigParser's eatChannelReference() removes the `queue:` or `tap:` prefix in the channel component only if the number of channel components is greater or than or equals 3. 

```

if (firstToken.data.equalsIgnoreCase("queue")) {
				channelType = ChannelType.QUEUE;
			}
			else if (firstToken.data.equalsIgnoreCase("topic")) {
				channelType = ChannelType.TOPIC;
			}
			// TODO: DT not sure if this is the best way to handle
			// StreamConfigParserTests.substreamsWithSourceChannels()
			if (channelScopeComponents.size() >= 3) {
				channelScopeComponents.remove(0);
			}
```

Which means,
if the channel name is `queue:job:jobname` then, the queue name will be job:jobname inside the message broker. 
if the channel name is `queue:something` then, the queue name still remains "queue:something". 

Based on this, if there will be a p2p named channel when binding the producer/consumer, then it can either have a prefix `queue:` or `job:`. 

Do you think we can remove the `queue:` prefix even in case of non-job named p2p channel?
While I am checking if there is any impact of doing this, I also see if we do that, then detecting named channels inside the LocalMessageBus becomes difficult (with the removal of aliasHint).