I recently witnessed a problem that proved to be fairly difficult to track down so I thought I would share the issue and resolution. In this case, a custom claims provider had been developed and it was being used as the default claim provider for the SPTrustedIdentityTokenIssuer, as described here: http://blogs.technet.com/b/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-provider-in-sharepoint-2010.aspx. It may appear to be working in some cases - you can search for something, it shows you the list of matches, you select one then click the OK button. In some cases, everything works fine - the dialog disappears and you see the resolved name in the type in control. In addition, you can also set a breakpoint on the FillResolve method and step through it.
In some cases though, you see this behavior:
In this case, what I finally determined what was happening is that the custom claims provider was adding a claim type that did not have a corresponding mapping in the SPTrustedIdentityTokenIssuer. So for example, it was creating a claim where the claim type was http://schemas.steve.com/foo, but the list of claim mappings for the SPTrustedIdentityTokenIssuer did not have a mapping for http://schemas.steve.com/foo (for an example of claim mappings and how they're created see http://blogs.technet.com/b/speschka/archive/2010/02/17/creating-both-an-identity-and-role-claim-for-a-sharepoint-2010-claims-auth-application.aspx). So rather than add a claim that SharePoint knows is not mapped, somewhere in the pipeline it just eats it and leaves you with a blank screen, and no error message. And that's why it can take so long to track down.
For this particular problem we ended up tearing down the SPTrustedIdentityTokenIssuer and recreating it, but adding a new mapping for the claim type that had been disappearing from the people picker. We ran the code again and it all "just worked" right away, so that confirmed the problem and resolution.