Serial numbers are designed to be used as keys in relationships so sequence doesn't matter, just uniqueness. What kind of feature are you trying to create? Maybe we can help if you describe what you want in more detail.
Not in any way that I'd recommend in a solution that might have more than one user creating records in this same table at the same time.
You may be able to change the field option to apply the serial number when the record is committed instead of when it is created, but this can cause other issues for you so you'll need to test carefully if you choose to use that option--can't create related records via a relationship based on such an auto-entered serial number field until the new parent record is committed if you do that, just to identify one particular issue.
Don't revert or delete records. If you find that your new record is not needed, "void" the record instead by setting a status field to "void" or some value that marks it as "void". Relationships, find criteria and portal filters can conceal keep such "voided" records from view, but if you need to account for every value in the series, the voided records can document the reason for the gaps.
Use Get (UUID) in a text field to assign primary key values and use your serial number as just a "label" field in the parent record and not for linking to other records in relationships. Then the "on commit" option should work for you to avoid unintential increments of the next value.
Just let there be gaps in the sequence. The main purpose of an auto-entered serial number is to produce a unique value to be used to match a parent record to one or more child records. As such, the fact that the value is unique is all that is really important, so while you might not like the "look", it won't affect database function. The only time that you really need a "gap free" sequence of serial numbers is:
For audit purposes to show that no records have been deleted.
The boss/client insists on it even though it is not necessary.
Change the serial number to generate on commit, not creation.
It is possible, however, to end up with the serial numbers out-of-order: one user creates a record and defers committing: a second user creates a record and commits before the first user commits. The second user's record will have an earlier serial number than the first user.