Ugyan nem a Rosetta2-ről szól, de anno a VMware binary translation egy nagyon hasonló problémát kellett, hogy megoldjon. Ebben a cikkben van egy elég részletes leírás az ugrási/elágazási címzés kezeléséről (3.2 fejezet): https://courses.cs.vt.edu/~cs5204/fall07-kafura/Papers/Virtualization/Binary-Translation-VMWare.pdf
Érdekes lenne tudni, hogy a Rosetta2 mennyire tér el ettől a megoldástól. Nyilván x86->ARM fordításnál jóval kevesebb "IDENT" (amikor az utasításhossz nem változik, nem csúszik el a címzés) lehetőség van, mint x86teljes->x86korlátozott fordításnál, emiatt lehet, hogy más stratégiát érdemes követni.
Mindkettőre igaz, hogy abból a feltételezésből indulnak ki, hogy az eredeti kód már erősen optimalizált volt az adott targetre, tehát nincs értelme költséges összevonási optimalizálási lehetőségeket keresni.
Ami még érdekes, hogy mi történik, ha az emulált program adatként próbál hozzáférni a saját kódszegmenséhez. Emiatt benn kell tartani a memóriában az eredeti (módosítatlan) kódot is az eredeti címen, valamint egy másik címen "shadow" kód szegmensben kell tartani az átfordított változatot, ami ténylegesen fut. Nyilván ennek rengeteg speciális esete van, ahol az emulátornak közbe kell avatkoznia, hogy a futó program ne vegye észre, hogy valójában nem is onnan fut, ahonnan kéne. A legrosszabb, ha az emulált program futási időben módosít is a kódján (mondjuk JIT compiler van benne). Számomra például különösen kérdéses, hogy az Ahead-of-Time compiler-ek, mint a Rosetta2 mit tudnak ezzel a helyzettel kezdeni. A JIT compiler-es emulátorok ezt könnyebben meg tudják oldani szelektív code cache invalidálással.