The specification suggests that there are "events" which signal sync objects. It also states that the "server" (it should also be made clearer what is meant by that term) waits on WaitSync( ) until a sync is signalled (i.e. the according event has occured) (4.1.1).
Section 4.1 only makes sense (and can agree with 2.1 "commands are executed in the order in which they are issued) if its made explicit that
1) The "execution" of a FenceSync is defined to be the insertion of the fence into the command queue (the "execution" is *not* the fence being triggered)
2) The "waiting of the server" as by "WaitSync" ought to be clearly defined as the GL SOFTWARE not issueing further instructions to the HARDWARE until the HARDWARE has performed all operations associated to the commands which were passed to the SOFTWARE before that point.
Otherwise, if we simply speak of the GL ("the server") taking commands and then "waiting" for a fence, imagine the following situation: The client issues the following commands
a( ); b( ); c( ); FenceSync( ); d( ); e( ); f( ); WaitSync( )
and the server starts processing them. At the time when "WaitSync is called", a( ) and b( ) have finished. IF THE SPECIFICATION WAS RIGHT, the server would now wait at c( ) for the FenceSync( ) to be reached. This will obviously deadlock the server!