it wasn't an oversight. there is no reason for a synchronous version. because of the ordering guarantees, if you issue an asynchronous sync, the next call, whether synchronous or asynchronous will see the updated state.
But in case of connection loss and absent of ZOOKEEPER-22, client has to check result of asynchronous sync before next call. So, currently, we can't simply issue an fire-and-forget asynchronous sync and an read to gain strong consistent. Then in a synchronous call chain, client has to convert asynchronous sync to synchronous to gain strong consistent. This is what I do in EagerACLFilterTest::syncClient, it is apparently unfriendly to end users.