AMQP Interoperability with Service Bus is dependent on TransportType - .NET Client vs. Proton-C

I have found a really strange behavior in the Service Bus interoperability implementation.

I am sending data from a .net client  (WindowsAzure.ServiceBus 2.7.3) to Proton-C Clients on various platforms (Win32, Linux, ...)

For the sake of simplicity I decided to use AMQP map format.

According to the table under the following MSDN article the .NET DataType IDictionary is mapped to AMQP map. 

https://msdn.microsoft.com/en-us/library/azure/jj841075.aspx

Sender:

 var brokeredMessages =
                    pointEvents.Select(pointEvent => new BrokeredMessage((IDictionary) pointEvent.AsDictionary())
                    {
                        MessageId = pointEvent.Id.ToString()
                    });

This is correctly mapped to AMQP MAP and can be deserialized on the Proton-C side with

Receiver:

const char * format = pn_message_get_content_type(message);
				pn_data_t *body = pn_message_body(message);
				pn_data_next(body);
				pn_type_t type =  pn_data_type(body);
				size_t mapsize = pn_data_get_map(body);

the message type in the body is PN_MAP(25) as long as .NET client uses TransportType=Amqp in connection string.

If the .NET client however switches the TransportType to NetMessaging (as I wanted to do because of some firewall issues)  the message body is serialized as PN_BINARY(19) instead.

The .NET library implies that AMQP is just a transport type, but it has actually a significant impact on the semantic of the communication.

I guess one might argue that you have to use AMQP Transport to have AMQP serialization, but I think this is at least an API design problem if not a straight forward bug....