If I understand the description correctly, there are two separate issues here.

One is a feature request like this:

https://lists.launchpad.net/maria-developers/msg05551.html

In current code, this is not implemented. So taking a cold backup without any
binlog files means the new server has no prior knowledge of used GTIDs,
effectively starting over as if RESET MASTER was done.

So with current code it is necessary to include at least one binlog file in
the backup (if executing FLUSH LOGS just before the cold backup, that
file can be made very small though).

The other part is that from the description the error messages in this case
are inaccurate, this should be fixed in any case.

Well, sure server has no prior knowledge of used GTIDs, that's why I execute SET @@global.gtid_slave_pos = '0-1-100'. Isn't that supposed to work? If not why?

Actually the use case can be simplified as the following: I bootstrap a new database and do it without any binlogging in the bootstrap mode, then I copy this new database to several servers. Then I start MariaDB on this copied databases and execute SET @@global.gtid_slave_pos = '0-1-100' because I want binlogging to start from this GTID. At this point if strict mode is turned on on all servers they cannot connect to replicate from one of them. Is this kind of bootstrapping not supposed to work? If yes then what should be changed in this process for it to work properly?

Ok, thanks for the clarification, I had missed the point about setting
gtid_slave_pos to get new master starting from specific GTID point.

So yes, it seems plausible that the error message in gtid strict mode
is incorrect. I will need to set up some test cases and investigate to
understand the details.

Not much has been done so far to handle removal of binlogs. But
as you say, having a slave without binlog, and promoting that to a
new master, is supposed to work; and that is quite similar to
what you describe.

Perhaps the problem is the code that detects when slave requests
to start in a "hole" in the master's binlog with gtid strict mode enabled
(0-1-99 and 0-1-101 exist but 0-1-100 does not). It needs a special
case for when 0-1-100 is not in the binlogs but is in the
@@gtid_slave_pos.

Do you think a special case when 0-1-100 is not in binlogs but it was in gtid_slave_pos and binlogs have 0-2-101 and higher should also be processed?

>Do you think a special case when 0-1-100 is not in binlogs but it was in
> gtid_slave_pos and binlogs have 0-2-101 and higher should also be processed?

Yes.

Kristian, could you say what's your priority on this? Is there an ETA?

We really need this and I'm starting to think that maybe I need to hack something about this myself...

Fix pushed to 10.0-base.

(There were two separate bugs. One the error in --gtid-strict-mode
and a different bug in the case of empty binlogs on the newly
provisioned master, as noted by the reporter in the original
description).