From the Apex documentation: "Each future method is queued and executes when system resources become available." As such, if the system resources are available, the @future method could execute immediately.

I would conclude there are no guarantees the timing will look like the first timing order you asked about below:

-start sync---call future---end sync---execute future->

This is exactly why, as you've astutely noted, the documentation states:

The reason why sObjects can’t be passed as arguments to future methods is because the sObject might change between the time you call the method and the time it executes. In this case, the future method will get the old sObject values and might overwrite them.

From the Apex documentation: "Each future method is queued and executes when system resources become available." As such, if the system resources are available, the @future method could execute immediately.

I would conclude there are no guarantees the timing will look like the first timing order you asked about below:

-start sync---call future---end sync---execute future->

This is exactly why, as you've astutely noted, the documentation states:

The reason why sObjects can’t be passed as arguments to future methods is because the sObject might change between the time you call the method and the time it executes. In this case, the future method will get the old sObject values and might overwrite them.

Edited to add:

If you want to ensure the above mentioned timing order, you'd want to perform any DML before calling @future methods.