FHIR Resources (upper case when referring to the specification) represent a flexible healthcare data model that can be applied to many different use cases when that data model is constrained by creating FHIR Profiles.  The interoperability is in the constrained FHIR Profiles, not in FHIR Resources.  It is true that the base FHIR standard is equivalent to HL7 v2.  The HL7 v2 is syntactic interoperability only, as is the base FHIR standard, and you cannot apply a "profile" to HL7 v2.  It is not possible. 

Semantic Interoperabillity is hard and it exists only if there is a shared semantic model = FHIR Profile used by the systems exchanging data.  The same profile, because it is possible to create different profiles for a use case that are reasonable models but are not the same. 

FHIR is neither the holy grail nor just another technology.  It does offer the potential to enable semantic interoperability.  And FHIR was created by the same people, the same organization that created HL7 V3.  Lessons learned in the failed HL7 V3 were part of what guided the development of FHIR. 

Thank you @Sylvain Guilbaud 
It's always fun to deliver this presentation and see the reactions.

I hope everyone will share with their networks.

The FHIR subscription architecture will change in FHIR R5.  The SubscriptionTopic Resource exists in FHIR R 5.0.0 snapshot but did not exist in R4.  Therefore it has maturity level 0.  Advancement of maturity level is a prescribed processs which requires use in connectathons as well as in production (once to level 3).  FHIR Subscription Resource is maturity level 2.  Maturity level does not relate so much to whether a Resource is implementable as it does to whether the Resource is likely to change.