You are correct; IDN and Active Directory support UTF-8, but you might see some unexpected behavior in Active Directory and other sources if you don’t convert diacritic characters in commonly used provisioning attributes, like user name and email. One approach you can take is to add additional identity attributes to hold transformed values of attributes that are commonly used in provisioning on sources. For example, firstName can be pulled straight from your authoritative source without any transformation, but you might want to create another identity attribute called preferredName that applies the diacritic transform to the firstName field, which you can then use in any sources that don’t support UTF-8. The same strategy can be used for email. You can create a second attribute called preferredEmail that is transformed.
I spoke to a member of Professional Services, and they suggest building distinguished, displayname, and email address in the Active Directory provisioning profile using transformed values so outlook address book renders them correctly. Ultimately, though, you can attempt to see how active directory will handle non-transformed values before committing your provisioning profile to production.