Personally i don't have a strong opinion about this. I would say if you choose for SKIP LOCKED, a whole table lock would include this, and thus no records would return. But i can imagine a whole table lock are for special cases like backups or alter's, in which case you do want to wait till it complets. I would leave it to the application to check if a full table lock is present, and decides what to do if these cases are important. But generally i would say, if you opt for lock skipping, that is what you would get, regardless the kind of lock.
I also see the point of not having the WAIT being interoperable with the SKIP LOCKED, as they are more or less are mutually exclusive.

Also I'm removing the interoperability of WAIT/NOWAIT with SKIP LOCKED reverting to MySQl-8.0 behaviour of an implicit no WAIT. If you have a desire for `WAIT` and `SKIP LOCKED` please so say so on MDEV-25433

Folks, can you comment on MDEV-25388 if have strong opinions if SKIP LOCKED should be blocked, or not, by table level locks (like 'LOCK TABLES' or a concurrent 'ALTER TABLE'). What should the behavior be?

Will be out in 10.6.0. Thanks for your patience all.

danblackour use case is indeed quite similar as described by terryburton's description. With the exception that we don't directly require an result from the database. Our setup is a follows; We've a set of MariaDB instances where we store the tasks/data in a raw format and simple format. The data is then processed by a set of threads/workers and then inserted into another (master)MariaDB instance using XA transactions. Each thread/worker is general and can process any kind of raw data. The worker process consists of 2 phases, so that locks on the table are minimized and in case the (master)MariaDB isn't available or slow, insertion of new data isn't affected by this.
In the first phase each worker/thread assigns a id to the raw record, thus essentially assigning it self to do the work in the future. This process is our critical phase, and is protected by

GET_LOCK('shared-id-between-workers')

. So that only 1 worker at the time can assign raw data to itself. This is where i would like to use the SKIP LOCKED feature like in an UPDATE. thus instead of:

SELECT GET_LOCK('shared-id-between-workers');

UPDATE rawdata SET workerid=1 LIMIT 1000;

DO RELEASE_LOCK('shared-id-between-workers');

have:

UPDATE rawdata SET workerid=1 LIMIT 1000 SKIP LOCKED;

The second phase simply does a

SELECT * FROM rawdata where workerid=1

, which theoretically just cause a read lock on only it's owning record (sporadically i think i suffer from a GAP lock), and not be in the way of any other workers or the ongoing insertion of new data.

As requested i've created a new issue for this; MDEV-25338
I've checked the code files, but i don't think i'll be able to create a PR for this. But if i can contribute in any other way i'm happy todo so.