For several operations, but in particular before and after executing a Propagation Task, Syncope queries the External Resource to see if a matching item is found, and it does that via ConnId's GetApiOp.
Such operation is implemented at Framework level, e.g. before reaching out any effective Connector, via a plain search where the key is the special __UID__ attribute and the value is the one passed as argument, alongside with ObjectClass.
Using GetApiOp used to make entirely sense in the old days of ConnId 1.3 and Syncope 1.1, when the Mapping Item identified as AccountId (now Remote Key) was forced to blank the external attribute name: in such cases, in fact, __UID__ was used as external attribute.
ConnId 1.4 slightly changed the way how the __UID__ attribute is managed: as a result, since Syncope 1.2, it is mandatory to specify an external attribute name for the Remote Key.
To give an idea, the 1.1 sample would result in querying the External Resource for
__UID__ == 'ilgrosso'
while the 2.0 sample from should result in
uid == 'ilgrosso'
but will instead produce the same query as in the past.
The problem here is that what actually __UID__ means is left to any Connector's implementation: LDAP configures that via the UidAttribute property (and GidAttribute in 1.5.2-SNAPSHOT), AD does something similar, others do differently.
From one side, in fact, the Remote Key is defined in Syncope at high level (e.g. as part of the Resource configuration, in the Mapping), while the raw __UID__ is still used under the hoods in some cases (before executing a Propagation Task, as said above, for example), hence it is the low level configuration (not Resource's but Connector's) that comes into play.
The improvement is to get rid of GetApiOp and replace its usage in Syncope with search, using as key the External attribute name defined in the mapping, rather than __UID__.
With reference to LDAP, in fact, with such change Users will be looked up by uid, Groups by cn and Realms by ou (if respective Mappings were set in these ways).