Let me give an 30-year experienced security architects feedback - not on the technology but on what I see as the value to a particular (US national-level) industry. I think this will hearten engineering types.
In our firm, which runs 30% of the US national (realty) MLS systems and nearly 100% of the LAN-based membership systems doing backoffice stuff (think CRM/Dynamics), we spent the last 5+ years SSO enabling all the systems. Competitive vendors did much the same thing, in a community-wide effort to adopt variants of SAML (and lots of half-assed SSO blobs based on MD5, too).
We have long had a vision for a cloud-based membership system, as we called it. What we meant was each of the 300 tenants we have should have a Azure AD instance.. now available. What we wanted was what is now delivered as the Directory Graph service (for 300 tenants), where we would happen to be the only party with write access. Rather than dirsync'ing entities, I envision construction "account" entities with whatever minimum is required (so SSO Authentication Statement from our IDP works, when supporting the Azure AD's STS with the likes of ImmutableID) and then any other properties are set by graph API usage (vs OOB dirsyncing, or the like)
The point is Im thinking of Azure AD as a SAAS-support service , and not (as in Office365) as extension of the enterprise (demanding tight cooperationg with the likes of ADFS).
I see absolutely NO POINT just building my own (read-only) directory graph, given Azure AD (and its pricing model).
Now, getting back to X.500 themes, there is a point I don't have clear yet. We have long had the notion that PER INDUSTRY REQUIREMENTS, some of the tenants (in realty) wish to share data as a mini-community - distinct from the others who continue to exist as stand-alone tenants who don't "share".
I see myself going one of two ways: (I) building a traditional metadirectory that aggregates tenants into several community, including hierarchical communities like X.500, or (ii) getting the community-of-interests configured using the security model.
Hope this context helps. The thing that makes this ALL possible (apart fomr the well build Azure AD for cloud-scaleability) is the correct architectural pattern in which we in our industry retain control of the IDPs (think ADFS) doing the user authentication and account control AND we retain master status of the attribute stores - viewing the slave directory as an (device) app-enablement platform.