Thanks!
A very detailed answer, as always. You’re right, the counter is a sequential client number, added to each lead (even before they’re a client, if at all). This will naturally create a situation in which two clients won’t have sequential numbers, even if they have been created one after a another (if a lead was created in between it’ll take that consecutive number). What I’ve done in the past is use the LockService on Google Script. It seems to be exactly what it is meant for, but it’s not very fast and it can create lags if we have many submissions at once, all asking the locked part of the script to generate a number for a new lead. I was really hoping to replace this (hardcore?) lock with a more elegant solution from Glide.
I’ve read all of the posts in the topic you linked and it seems that indeed these dragons hunt many of us 
I very much liked your video example.
However, I’m still puzzled by the race condition. Have you ever received feedback from Glide about this?
Same question, different approach, have you ever found out a way to force an action to be on the server-side? Specifically, having the compound action of “incremate” happen on the server. This will, hopefully, complete remove any chance of a race condition, even if two forms are submitted at the exact same time.
I very much liked your idea of having a separate table for the custom form, as well as the column that has the same value in all rows (next number), inside the data table. Again, this one-row custom form table isn’t immune to the race condition. Or is it?