The result of a Merge is that the two identities of a Patient are linked, one become master, and all the data recorded against both are considered one Patient. This means that a system implementing the Profile will treat a query request for one of the identities as if it was a query against all the linked identities. Putting the burden of link management and comprehensiveness of the query results upon the server, so that applications don't need do multiple queries to get a comprehensive patient record.
There is expected further refinement of this after Public Comment, and in coordination with HL7 Patient Administration workgroup efforts on the same topic. It is possible that a formal Merge will be supported, but in FHIR a Merge comes with some downsides. When FHIR is a front-end to a non-FHIR system (e.g. an EHR), the result will likely look like a Merge, in that only the surviving identity will ever be seen from again. Where as a native FHIR Server is used, a link is more friendly to the integrity of the data persisted in FHIR Resource form. Especially if those FHIR Resources have digital signatures on them.
What we also don't quite know is how to scale a Patient Identity Management system to a very large federation. How to keep track of communities that are behind communities (nested communities). What additional functionality that FHIR can bring to the table, what issues will appear once we start using FHIR Resources to discover the locations where Patient Data exists. It feels like this will be easy, it feels like we have learned from v2 and v3; but there is always dragons hiding.
So, yes HL7 v2, v3, and FHIR (four) will be used together for different endpoints. The common factor is the Patient Identity, Patient Demographics, Patient Address, Patient Phone Numbers, and other non-patient identifiers like SSN, Drivers License, Insurance ID, etc...