POST accessPackageAssignmentRequests fails using target.email when user's sign-in is blocked

Question

Creating a new Access Package Assignment Request using target.email fails for Guests where Sign-in blocked = Yes.

Example 5: Admin requests a direct assignment for a user not yet in the directory shows us how to create an Access Package Assignment Request for a Guest that is not yet in our tenant:

   POST https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests  
   Content-type: application/json  
   {  
     "requestType": "AdminAdd",  
     "accessPackageAssignment":{  
        "target": {  
           "email": "******@contoso.com"  
        },  
        "assignmentPolicyId":"2264bf65-76ba-417b-a27d-54d291f0cbc8",  
        "accessPackageId":"a914b616-e04e-476b-aa37-91038f0b165b"  
     }  
   }  

This fails when user@Company portal .com is already in our tenant and their Sign-in is blocked:

   BadRequest: "The invited user already exists in the directory as object ID: {GUID}, but the account is blocked from signing in. If the account is unblocked, they can use that account to sign in to shared apps and resources."  

If their Sign-in is not blocked then it succeeds. Making the call with targetId ALSO succeeds:

   POST https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/accessPackageAssignmentRequests  
   Content-type: application/json  
     
   {  
     "requestType": "AdminAdd",  
     "accessPackageAssignment":{  
        "targetId":"46184453-e63b-4f20-86c2-c557ed5d5df9",  
        "assignmentPolicyId":"2264bf65-76ba-417b-a27d-54d291f0cbc8",  
        "accessPackageId":"a914b616-e04e-476b-aa37-91038f0b165b"  
     }  
   }  

My organization allows B2B partners to onboard their staff to our applications using this API call. It's not reasonable for us to give them read access to our users just so they can check for this case (an existing Guest with Blocked Sign-in). We need them to be able to request assignments for their users by e-mail address regardless of whether or not the Guest already exists in our directory (that's how the API is currently implemented) and regardless of whether or not that existing Guest is blocked.

It looks like there's some extra validation on the call that is checking for blocked sign-ins when target.email is used to identity the Guest, but that validation is not present when targetId is used instead. We'd like these to work the same way (ignore blocked Sign-ins).

From a reasonableness perspective, failing when Sign-in is blocked doesn't make sense: it's not a blocker for entitlements (placing a user into a Group, etc.) and it can happen without warning to any Guest in any tenant based only on Risky Sign-in policies.