It still works in 10.2.0, but fails starting with 10.2.1, then again it works again starting from 10.4.0.

I tried to track the actual change down with git bisect, but failed

I also tested this on MySQL, where it is supported starting with 5.7, and with postgreSQL 10.6, which also supports it.

There was a discussion about WHERE without FROM triggered by MDEV-16981. At that point, the conclusion was that WHERE without FROM is against the standard, and it working before 10.2 was a parser glitch.
Apparently, changes in 10.4 have made it possible again.

Assigning to bar for further handling.

WHERE and FROM in not usual order

sanja the WHERE is on a different SELECT than the two FROMs:

SELECT (

          SELECT id1 

           WHERE id1 IN (

                           SELECT id2 

                             FROM t2

                        )

       ) AS result 

  FROM t1;

SELECT 1 WHERE 1; was never working, so actually we should fix cases where it was allowed in subqueries (something completely different from the author wish)

The question is do we really want fix it is vaerions < 10.2, also how urgent is to prohoibing it in 10.4+ ?

I re-tested on other databases, with the result:

MySQL -> query works in 5.7. and 8.0, but not in earlier versions

PostgreSQL -> works with 10.6 and 11.5

SQLite -> does not work with 2.8, but does with 3.29

So we may change this back to "not working"; but I'd probably have a hard time to convince the customer that we are doing "the right" thing while at least all major other open source contenders, even pgsql who are usually more strict on such things that we are, decided to do the opposite ...?

PS: I don't remember having changed the priority?

It is 10.2:

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019

create table t1 (a int);

select * where a=1 from t1;

main.test                                [ fail ]

        Test ended at 2020-02-13 13:33:57

CURRENT_TEST: main.test

mysqltest: At line 3: query 'select * where a=1 from t1' failed: 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'where a=1 from t1' at line 1

So what is working in 10.2?

Other example from 10.2:

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019

set @a=1;

select @a where @a=1;

main.test                                [ fail ]

        Test ended at 2020-02-13 13:51:07

CURRENT_TEST: main.test

mysqltest: At line 3: query 'select @a where @a=1' failed: 1064: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'where @a=1' at line 1

 - saving '/home/sanja/maria/git/10.2/mysql-test/var/log/main.test/' to '/home/sanja/maria/git/10.2/mysql-test/var/log/main.test/'

As it works the same as it did in 10.2 and 10.3 with current versions of MySQL, PostgreSQL, SQLite I still think the current 10.4 behavior is a regression bug, and the 10.2/10.3 behavior should be restored ...

I don't quite understand from the bug report, could you elaborate please?

What worked in 10.2 and 10.3 and doesn't work in 10.4?

The test case given in the initial description as "how to reproduce" works fine on MariaDB 10.2, 10.3 – and also on current versions of MySQL, PostgreSQL and SQLite--, but with 10.4 it gives the shown syntax error again, as it did in 10.1 ...

Ok, now I confused myself, too.

10.1, 10.4 and 10.5 work, it is 10.2 and 10.3 where the syntax error is thrown, so this is a regression in 10.2 and 10.3 that was only fixed in 10.4 again somehow (the "Affected versions" field, and the very first sentence in the initial description, say so, looks as if I got confused about this over time myself ...)

So what's actually wrong IMHO is the fix version. There's nothing to be fixed in 10.4, it's behaving fine in this respect. It is 10.2 and 10.3 that need fixing, or a clear "won't fix, upgrade to 10.4 if affected by this"