I assume the two IdPs configurations you set up in Keycloak are then pointing to the same actual IdP on the customer side, as otherwise there would be different user details provided by the IdPs, and that could IMHO mix up the data stored in Keycloak.

There is a mechanism in Keycloak to have the user choose between the organizations they are part of.

I think the following could help in your setup:

• Set up one "production" organization, and link the IdP there.
• Set up a second "test" organization, and invite those users who should be able to access the test system to the test organization.

If a client wants to know about the organization, it can pass different values via the organization scope to choose to learn about all the organizations user is part of, have the user choose one organization, or the client can provide an organization hint. See https://www.keycloak.org/docs/latest/server_admin/#_mapping_organization_claims_ for the docs.

The different IDPs for the customer could point to the same EntraID, but with different apps there, or different instances of Octa with the same HR system behind for the users in the Octa system. We haven't seen problems with this approach, the users are linked to both IDPs in Keycloak, as the user attributes for the linking are the same for both IDPs.
Do you know why the decision is taken to hide other available IDPs for a user when the user is connected to any IDP already?

I assume one didn't see the use case for that, and I see that using different IDPs would work in your case, but not in a general case. Maybe @keycloak/core-iam has more insights for that.

While I see why chose the setup in your current setup, I don't see yet if a similar user experience can be achieved with the options available in Organizations.

It would be great to know why the other IDPs are hidden, if there is already an IDP linked for the user. I'm sure it's intentional, but I just don't understand it and it would help me if it weren't so.