Bicep version
0.13.1

Describe the bug
When trying to create a recovery services vault via bicep and setting both a systemassigned and a userassigned identity both identities get created (serviceprincipal for the systemassigned, managedidentity resource for the userassigned) but none of the get attached to the Azure Recovery Services Vault. However, when calling the REST API directly with the following code:

$body = @{
    'properties' = @{
        'publicNetworkAccess' = 'Disabled'
    }
    'sku'        = @{
        'name' = 'Standard'
    }
    'location'   = 'West US'
    'identity'   = @{
        'type'                   = 'systemassigned,userassigned'
        'userAssignedIdentities' = @{
            '/subscriptions/subscriptionid/resourcegroups/testRSV/providers/Microsoft.ManagedIdentity/userAssignedIdentities/testRSV' = @{}
        }
    }
}
$restUri = 'https://management.azure.com/subscriptions/' + $SubscriptionId + '/resourcegroups/' + $ResourceGroup + '/providers/Microsoft.RecoveryServices/vaults/' + $VaultName + '?api-version=2022-10-01' #&operation=DeleteVaultUsingPS
Invoke-RestMethod -Uri $restUri -Headers $authHeader -Method PUT -Body ($body | ConvertTo-Json -Depth 99)

the creation and the assignment succeed.

Upon running the same code but with

'type' = 'SystemAssigned, UserAssigned'

the creation succeeds but the assignment fails.
When running the equivalent code in bicep the assignment never happens, no matter the configuration.
The chosen API-Version does not seem to impact this behavior.

A clear and concise description of what the bug is vs what you expected to happen

To Reproduce

1. Create a user assigned identity in the azure portal.
2. Create a bicep file which creates a recovery services vault and make sure to enable both system assigned and user assigned identities at the same time.
3. Run the bicep file.

Additional context
This is especially troublesome since you are no longer able to delete the rogue system-assigned identity (which is a service principal) without a support ticket.

cc: @JPEasier