In the current architecture, it is impossible for this to happen. Within a single transaction, ID values are assigned sequentially from a pool of ID values. A Salesforce instance is called a "pod," and within each pod are a number of application and database servers, plus a load balancer to distribute transactions across these servers. The load balancer tends to route sequential API requests for the same user session to the same server.
Each pod has a global ID counter for each key prefix. When a server wants to assign ID values, it reserves out a block of ID values and assigns them during the "Saves the record to the database, but doesn't commit yet" step of the Triggers and Order of Execution guide.
This is always in sequential/incremental order within the same transaction (so, a record earlier in the transaction will always have a "lower" Id than a later record), and generally sequential in transactions by the same user in transaction order (assuming no other user happens to get load balanced to the same server and grabs an ID). If a chunk is exhausted partway through a transaction, the Id values could skip forward, but will still be incremental.
So, within a single transaction, Id values will be ever increasing, and for any given user session, they will generally be ever increasing (assuming they are not rerouted by the load balancer), but for transactions from multiple users (or multiple sessions for the same user) in a short period of time, they may appear out of order chronologically if those user sessions are spread across multiple servers.
Given your example, the answer is no.
However, the following could certainly be possible:
| Transaction |
Insert Order |
ID |
| 1 |
1 |
1 |
| 2 |
2 |
4 |
| 2 |
3 |
5 |
| 2 |
4 |
6 |
| 3 |
5 |
2 |
| 3 |
6 |
3 |
This example assumes that transactions 1 and 3 belong to one user/session, and transaction 2 belongs to a separate user/session.
tl;dr
It is not possible in the current architecture for Id values to be out of order within a single transaction, but it is perfectly possible for ID values to be out of chronological order for transactions from multiple users within a short period of time. Transactions that happen much later (e.g. hours or days) will definitely have a "higher" Id value, as Salesforce does not recycle ID values (e.g. from permanently deleted records or records rolled back in unit tests or partial DML failures with allOrNone behavior set to false).
Also, this this related Q&A.