Converting mailboxes already migrated to Exchange Online to Shared mailboxes

SaschaSeipp , thanks for the comment! I'll answer in line :

• If the cloud mailbox has the status of Shared mailbox and OnPrem Exchange still "thinks" it is a user mailbox, then via AADC, the cloud is able to convert it (back) to a user mailbox. If that functionality is in there, then why not provide the correct way for the intended changes?! (Probably kind of the same question as @hatsikidee posted before).  -->For this specific scenario, it's a limitation from the cmdlet Set-RemoteMailbox -Type when it comes to Migrated mailboxes. It wasn't designed to handle Migrated ones this way, so it has this behavior that looks unexpected since you see the info correctly in the source of authority from OnPrem, but cloud doesn't update accordingly. This is not something that can be modified at this time.
• Those Shared mailboxes directly created via New-/Enable-RemoteMailbox -Shared should have the RemoteRecipientType "ProvisionMailbox" and hence don't have the problem from Ex2016 CU10 on, right? --> Correct. The parameter was introduced with that version going forward and was catered for ProvisionMailbox .
• If the currently more or less Microsoft supported way to fix this problem is to directly fiddle with AD properties, wouldn't it be easier to change all the mailboxes with RemoteRecipientType "Migrated" to "ProvisionMailbox" and be done with the problem once and for all (at least for those customers that don't need to migrate OnPrem mailboxes any more)? Obviously this would need to be made possible in Exchange Online, which I suppose it is not right now.  --> The preferred and classic workaround would be to offboard - modify while on premises - onboard again, but we're aware that this is not something that is always possible (especially for customers that started in Exchange hybrid, migrated everything to cloud and only kept an Exchange server for management purposes). Manually fiddling with AD properties in general is something we usually don't want unless there's a KB mentioning it as a workaround (if in a KB, it means it got tested specifically for that scenario and there shouldn't be any surprises).