Baker: minimal_timestamp flag

Related to MR: !7473 (merged)

Context

I'm wondering if there is/should be a difference between minimal_timestamp=true and minimal_timestamp=false when the protocol is activated with ~timestamp:Now in Tezt.

minimal_timestamp=true is the default value when calling e.g. bake_for_and_wait. If the protocol activation's timestamp is in the past, it allows baking successive blocks quickly in the past, and the chain will not catch up.

On the opposite, with minimal_timestamp=false, the baked block allows to catch-up. A subsequent call to bake will hold until it's time to emit the next block.

However, I noticed that when I initialize the protocol with ~timestamp:Now, baking with minimal_timestamp=false hold a few seconds as expected before producing a block, but baking with minimal_timestamp=true returns an error Block in the future:

[14:16:11.880] [client2] Jan 23 15:16:11.880 - alpha.baker.actions: Voting pass for liquidity baking toggle vote
[14:16:11.885] [node1] Jan 23 15:16:11.885 - validator.block: block at level 2 successfully pre-applied:
[14:16:11.885] [node1] Jan 23 15:16:11.885 - validator.block:   Request pushed on 2023-01-23T14:16:11.880-00:00, treated in 3us, completed in 4.249ms
[14:16:11.897] [client2] Error:
[14:16:11.897] [client2]   Block in the future.
[14:16:11.901] client2 exited with code 1.
[14:16:11.901] [error] client2 exited with code 1 (full command: ./octez-client --endpoint http://localhost:16385 --base-dir /var/folders/b4/9mtbn8lx79v12xzmzlcrct_40000gn/T/tezt-20381/1/client2 bake for bootstrap1 --minimal-timestamp)

Question

Shouldn't the semantics of minimal_timestamp=true and minimal_timestamp=false be the same when the latest block's timestamps is not (far) in the past?