The multiple matching grants were never stacked. I guess (in absence of full information), that you have both user@localhost accounts, as well as
user@127.0.0.1 . Both accounts match the user exactly. and if you log in on the local host, it is (and always was), strictly speaking, undefined, which of 2 accounts you'll end up with. 10.4 prefers "user@localhost", and depending on phase of the moon and on the order the accounts were defined in the mysql.user, maybe in 10.3 you got "user@127.0.0.1". In case like yours, please make sure that both accounts have the same grants.

I only have @127.0.0.1 definitions on this server:

both select count(*) from mysql.user where Host='localhost'; and select count(*) from mysql.db where Host='localhost'; return 0

I've updated the original report-description. I realize 'stacked' might not be the proper term - but can you confirm whether or not the behavior as described in the testcase is correct or not?

Thanks! Reproduced as described on 10.4, test passes on 10.3:

create database `j-test`;

create table `j-test`.t1(id int);

create table test.t1(id int);	

create user 'jtest'@localhost identified by 'jtest';

GRANT SELECT ON `%test`.* TO 'jtest'@localhost;

GRANT SELECT, INSERT, DELETE ON `j-%`.* TO 'jtest'@localhost;

show grants for 'jtest'@localhost;

connect conn1,localhost,jtest,jtest,test;

insert into `j-test`.t1 values (1);

select * from test.t1;

disconnect conn1;

connection default;

drop user 'jtest'@localhost;

drop database `j-test`;

drop table test.t1;

create database `j-test`;

create table `j-test`.t1(id int);

create table test.t1(id int);

create user 'jtest'@localhost identified by 'jtest';

GRANT SELECT ON `%test`.* TO 'jtest'@localhost;

GRANT SELECT, INSERT, DELETE ON `j-%`.* TO 'jtest'@localhost;

show grants for 'jtest'@localhost;

Grants for jtest@localhost

GRANT USAGE ON *.* TO 'jtest'@'localhost' IDENTIFIED BY PASSWORD '*8EFCF76F0D8572B6A29E56D50FFD82F96F44E78B'

GRANT SELECT ON `%test`.* TO 'jtest'@'localhost'

GRANT SELECT, INSERT, DELETE ON `j-%`.* TO 'jtest'@'localhost'

connect conn1,localhost,jtest,jtest,test;

insert into `j-test`.t1 values (1);

main.1_my                                [ fail ]

        Test ended at 2019-07-31 11:57:20

CURRENT_TEST: main.1_my

mysqltest: At line 14: query 'insert into `j-test`.t1 values (1)' failed: 1142: INSERT command denied to user 'jtest'@'localhost' for table 't1'

This is not a bug. Old behavior was incorrect. The documentation states that all grants are sorted in order from most specific to least specific. And the first matching grant is applied. You have

GRANT SELECT ON `%test`.* TO 'jtest'@'127.0.0.1';

GRANT SELECT, INSERT, DELETE ON `j-%`.* TO 'jtest'@'127.0.0.1';

and you expect INSERT INTO `j-test`.t1 to work (grant on j-% is applied, not grant on %test).

This used to work because MariaDB incorrectly sorted %test grants after j-% grants, considering j-% grant as "more specific". This was incorrect, because there are fewer valid database names that match the %test pattern, so it is more specific and should've been sorted first.

This bug was fixed in 10.4.

Note, that if you swap your grants, like in

GRANT SELECT ON `j-%`.* TO 'jtest'@'127.0.0.1';

GRANT SELECT, INSERT, DELETE ON `%test`.* TO 'jtest'@'127.0.0.1';

you'll get an opposite effect, INSERT INTO `j-test` will work in 10.4 and will fail in 10.3.