.NET SDK doesn't support IdP routing rules in version 6.0.0

If I retrieve a list of policy rules from GET /api/v1/policies/{id}/rules, I get policy rule objects that look something like this (many details omitted):

{
    "id": "0pr11s4jgj7B6d425417",
    "status": "ACTIVE",
    "name": "Example Rule",
    "conditions": {
        "userIdentifier": {
            "patterns": [
                {
                    "matchType": "SUFFIX",
                    "value": "example.com"
                }
            ],
            "type": "IDENTIFIER",
            "attribute": "login"
        }
    },
    "type": "IDP_DISCOVERY"
},

The part I’m interested in is what’s inside the “conditions” node. I want to look up a list of valid domains based on the IdP policy rules that exist in all routing rules, and the routing rules are modeled as policy rules. Notice that the rule object has “type”: “IDP_DISCOVERY”, so it’s getting the correct rule objects back.

My problem is that in the .NET SDK, if I do ListPolicyRules() I don’t get access to the conditions, or other values that are specific to routing rules. It seems to be a problem with the new polymorphism that was introduced in version 6 of the SDK. I can see that the values are there in the JSON response from the server, but they don’t get deserialized with all the necessary properties into the PolicyRule objects.

The reason seems to be that there is no IdentityProviderPolicyRule defined in the SDK. There is for example one called AccessPolicyRule, and another one called AuthorizationServerPolicyRule, but the IdP one seems to have been forgotten. I assume this is something that’s missing in the OpenAPI definition of the endpoint.

In version 5 of the .NET SDK this was not a problem, because the polymorphism worked differently, so I had access to the conditions directly on the PolicyRule object. The new type definitions seem better than the old one, but when the specific type is missing it makes me impossible for me to upgrade to the new version.

Can someone confirm if this is indeed a blind spot in the API type definitions?