This information is provided under the openness paradigm that guides the development of midPoint. MidPoint is a great software product. But it is also a practical software product developed in a pragmatic way. Therefore midPoint is not perfect. The goal of midPoint is to fulfill practical goals and solve problems that affect midPoint subscribers right now. Therefore it is perhaps completely understandable that midPoint has its drawbacks.
In the spirit of openness that is embedded in midPoint development culture we do not try to cover midPoint's drawbacks. We try hard to communicate all midPoint limitations and drawbacks very openly. Even if midPoint has some issues, as far as we are aware those issues do not invalidate midPoint architecture and design. As far as we know it is perfectly feasible to address all those issues. And that is exactly what midPoint platformsubscription platform subscription can be used for.
TODO: not a problem with ConnId, but may be a problem with async approaches
TODOThis problem did not affect midPoint deployments too much when ConnId connectors were the only mechanism to detect changes. Due to limitations of ConnId that are inherited from the past the connector cannot detect fully relativistic changes anyway. The connector usually returns complete new state of a resource object (e.g. account). Therefore there is no penalty in using that absolute state in the computations in this case. However, the requirements may gradually change when new asynchronous method of change detection are introduced, such as messaging resources.
The plan is to improve implementation of Clockwork and Projector to support completely relativistic mode. This will make the algorithm more complex and it is very likely to trigger several refactoring waves over existing code. But according to our evaluations this approach is completely feasible. It is also the right thing to do to align the implementation with the original desig and the ideal of relativity.