CentOS Linux release 7.4.1708 (Core)

Sorry, I don't understand the nature of the problem here. For the result which you consider to be wrong, please indicate what result you would expect instead, and why.

The confusion is understandable. A SQL sequence is not what is called a sequence in math. A SQL sequence is a series of unique numbers intended to be used as, and enhance, the concept of auto_increment.

A 'sequence' in SQL as defined in ANSI SQL:2003 should return a list of unique numbers. Reference implementations such as Oracle and IBM also expect uniqueness.

In the case described, the number 4100, which is the 'next value' returned for the sequence in node 1, is equal to the number 4100, which is the 'next value' returned for the sequence in node 2. In other words, multiple calls to 'next value' for the same sequence in multiple Galera nodes return the same, duplicate, value. ie. sequences don't work in Galera for MariaDB 10.3.7, as they produce duplicate numbers in the same cluster.

So to be clear, it is wrong for 2 calls to 'next value' for the same sequence to return the same value. In the case of a Galera installation it is wrong for two calls to 'next value' for the same sequence from 2 nodes to produce the same value.

Thanks.
The confusion was not about the scientific meaning of sequences, but about the form of the bug report.
Anyway, the scenario is overcomplicated. The problem is unrelated to re-bootstrap (or to Galera, for that matter). If you had run nextval(s) on the 2nd node right away, before any restart, you would have seen it already – the second node would have returned 100 instead of the expected 102. The simple matter of fact is that with certain combinations of sequence parameters and auto_increment_* values, the offset does not get applied. The rest is just variations.

Here are some examples where it raises from questionable to obviously wrong.

set global auto_increment_increment= 2, auto_increment_offset= 1;

create sequence s start with 1 increment 0;

select nextval(s);

nextval(s)

1

This is questionable. Should it really be 1, or should it be 2 (start value + offset)? It might seem okay that it's 1 at the first glance, but then

set global auto_increment_increment= 2, auto_increment_offset= 1;

create sequence s start with 100 increment 0;

select nextval(s);

nextval(s)

101

This seems logical, and here the offset is applied? So, it's inconsistent with the previous example.

Further, if we have

set global auto_increment_increment= 2, auto_increment_offset= 2;

create sequence s start with 2 increment 0;

select nextval(s);

nextval(s)

2

Same case as with the first example above, again questionable, it might seem okay, but then

set global auto_increment_increment= 2, auto_increment_offset= 2;

create sequence s start with 100 increment 0;

select nextval(s);

nextval(s)

100

Now, this is obviously wrong.

In terms of your rebootstrap scenario, it boils down to this.
First, you create the sequence on node 1 of a 2-node cluster, thus the node has auto_increment_increment=2 and auto_increment_offset=1, so the "good" logic works:

set global auto_increment_increment= 2, auto_increment_offset= 1;

create or replace sequence s start with 100 increment 0;

select nextval(s);

nextval(s)

101

but then, when you rebootstrap the cluster and start only one node, which means at this point it has auto_increment_increment=1 and auto_increment_offset=1, so this logic works instead

flush tables;

set global auto_increment_increment= 1, auto_increment_offset= 1;

select nextval(s);

nextval(s)

2100

or, in other terms,

set global auto_increment_increment= 1, auto_increment_offset= 1;

create or replace sequence s start with 100 increment 0;

select nextval(s);

nextval(s)

100

– no offset.

Then you start the second node, which gets auto_increment_increment=2 and auto_increment_offset=2, so it works like this

set global auto_increment_increment= 2, auto_increment_offset= 2;

create or replace sequence s start with 2100 increment 0;

select nextval(s);

nextval(s)

2100

All in all, the logic is flawed in the calculation of the initial offset, it's just less obvious when start with value is default. I've briefly looked into the place where it's calculated, there are many rather conflicting conditions and branches, so it's not surprising.
MDEV-16313 is probably another indication of the same problem (for a debug version), and not just a bogus assertion failure.

First auto_increment_increment= X and auto_increment_offset= Y doesn't affect the initial value for a sequence, except if it's not part of the sequence that these two variables are generating.

set global auto_increment_increment= 2, auto_increment_offset= 2;
create sequence s start with 100 increment 0;
select nextval(s);
nextval(s)
100

Is perfectly fine as 100 is part of the sequence 0,2,4,...98,100,102 and so one.

The problem is probably, as Elena stated above, related to the new nodes doesn't have the variables set properly.
For things to work, all nodes should at all times have the same auto_increment_increment value and at all times have a fixed (for that node) and different to all other nodes auto_increment_offset.

Given the above, I happily close the issue.