I'm guessing your question relates to the missing values (29-40) for the first sequence.

If so, this has to do with the caching of sequence values. When you get the nextval for a sequence, the database automatically generates the next N numbers and caches them. The value of N is whatever you've set CACHE to. (Though in 21c the database is able to auto-tune the number of cached values; so treat this as a minimum rather than a fixed N from that release on).

If you leave the sequence untouched for a while, eventually the database will purge these cached values. You can simulate this by flushing the shared pool.

When you next access the sequence, it'll continue from whatever the last cached value was plus one.

The second sequence doesn't miss any values because you were lucky: 1620 is a multiple of the cache (20). If it had ended on any value that isn't a multiple of 20 it would have skipped values too.

You can see what the next value would be if the cache is lost by querying *_sequences.last_number. For example:

create sequence s;

select last_number, cache_size 
from   user_sequences
where  sequence_name = 'S';
/*
LAST_NUMBER CACHE_SIZE
----------- ----------
          1         20
*/
select s.nextval from dual;
/*
   NEXTVAL
----------
         1
*/
select last_number, cache_size 
from   user_sequences
where  sequence_name = 'S';
/*
LAST_NUMBER CACHE_SIZE
----------- ----------
         21         20
*/      
alter system flush shared_pool;

select s.nextval from dual;
/*
   NEXTVAL
----------
        21
*/