No worries at all! This is a complex topic and there is a lot to unpack, all questions are welcome to help yourself and the wider audience grasp the concepts behind exchanging clinical data between OpenMRS/Bahmni instances.
When I said that openmrs-eip’s dbsync module was not a substitution to HIE patterns, I just voiced a caveat to properly outlines what it does or doesn’t do. In short: it allows to exchange clinical data between OpenMRS instances, simplifying some of the typical HIE-related problems because it operates in an OpenMRS-only environment.
You would need to fully embrace HIE patterns when you cannot make much assumptions about the nature of the components within the HIE. For instance if you operate within a network of EMRs instances that need to exchange patient files, and that those EMR systems are from different vendors, then you cannot make too many assumptions. You may just want to require that they all speak FHIR and then orchestrate interoperability on that (high level) principle. But if you know that you operate within a network of OpenMRS EMR instances, then you can simplify a number of things because much of the interoperability potential arises simply from the fact that it is an “all OpenMRS” environment. That is what openmrs-eip’s dbsync does.
There is no concern about mismatching ids between databases, this is solved through the internal mechanics of dbsync.
Note that since you last wrote, the work that ensures that dbsync can support two-way sync has already progressed and is well on track. While it is not ready yet, you can either assume it will eventually be or you could get involved in fast tracking that part of the openmrs-eip roadmap.
Bahmni Connect is a completely different story. It is a mobile app (a PWA actually) that can cache some of the OpenMRS data to function fully offline for some time. It is just about in-browser data caching, it is a completely different topic than EIP or data exchange between EMR systems.