As part of some claims based authentication work I've been doing recently, I've come across two very important constraints.  They are manageable constraints, but they are things that you need to know about in advance of setting up and configuring your claims infrastructure in SharePoint 2010.  The big items to be aware of:

• Certificate Uniqueness Required for SPTrustedIdentityTokenIssuer - when you create a new SPTrustedIdentityTokenIssuer, one of the parameters that you provide is the ImportTrustCertificate.  This parameter is an X509Certificate2 object, and is the certificate that you export from your STS (like Geneva, AKA as ADFS v2, Server).  Once you use that certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it again to create another one.  If you want to use that certificate in another SPTrustedIdentityTokenIssuer, you will have to delete the existing one first.  And before you can delete an existing one, you would have to disassociate it with any web applications that may be using it.  I bring this up because if you try to create another SPTrustedIdentityTokenIssuer with the same certificate it will fail, but the error message really isn't going to tell you that the certificate is the problem.
• Claim Mappings are Immutable - when you create your SPTrustedIdentityTokenIssuer you identify the claims that you want that SPTrustedIdentityTokenIssuer to accept.  If your STS sends over additional claims they will be dropped by SharePoint when the SPClaim is created.  The important thing here is that after you have created your SPTrustedIdentityTokenIssuer, you cannot change the set of claims it accepts.  PowerShell will let you make changes and call update, but under the covers we don't do anything.  Hopefully this behavior will be changed by RTM to at least throw an exception when you try this, but it's not clear if that will happen or not.  From an implementation perspective the fact that you're locked into a set of claims after you create your SPTrustedIdentityTokenIssuer is pretty manageable.  At the end of the day, pretty much everything we do in SharePoint can be wrapped in an identity and role claim.  The beauty of the role claim is that if you have other attributes that become interesting over time, you can plug it into the role claim.  It simply expands or contracts depending on your group memberships.  To see how to add both an identity and role claim to an SPTrustedIdentityTokenIssuer, see my posting at http://blogs.technet.com/speschka/archive/2010/02/17/creating-both-an-identity-and-role-claim-for-a-sharepoint-2010-claims-auth-application.aspx.

** UPDATE **

There has been some scripts that have shown in some cases they can seemingly update the list of claim mappings associated with the SPTrustedIdentityTokenIssuer after the fact.  After discussing with some folks on the claims test team, the advice is to not use those - you should consider the claim mappings immutable with the RTM release of the product.  That may change in the future, but for the RTM release this is how we're going to address it.

So, these are important constraints to be aware of, but they can definitely be managed without too much fuss as long as you are aware of them up front.