Two years since MySQL supported this and no progress on this fundamental feature unfortunately.

Am aware that we can use a kludge for this:
Persistent columns - but it reminds me of Firebird years ago when a similar kludge was needed
(extra column populated by a trigger).

Eventually Firebird (always kept close to ANSI standards, don't know if this syntax is or not) but they implemented:
*CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX <index name> ON <table name>
COMPUTED BY ( <value expression> )*
And this was transparent to the user. No extra fields, no extra triggers, and was able to use these indexes where ORDER BY queries contained the COMPUTED BY expression.

Be great to have something similarly implemented but if not then - in 2020 - just:
*CREATE [UNIQUE] [ASC[ENDING] | DESC[ENDING]] INDEX <index name> *
where the DESC clause wasn't ignored, would be beyond most welcome.

Genuine thanks for all the work

It was missing in MariaDB 10.6, and it is also excluded in the 10.7 plan.
Surprisingly, there are many cases of choosing MySQL between MySQL and MariaDB for performance issues caused by this problem.

For those who were wondering whether MyRocks upstream supports these indexes: it doesn't:

mysql> create table t1 (a int, b int, key(a desc));

Query OK, 0 rows affected (0.05 sec)                                                                                                  

mysql> alter table t1 engine=rocksdb;

ERROR 1178 (42000): The storage engine for the table doesn't support descending indexes                                               

This is latest fb-mysql-8.0,

commit 0a03beadc6f4a9aa247ee2e886b542ff02182f0c (HEAD -> fb-mysql-8.0.20, origin/fb-mysql-8.0.20)

Author: Chi-I Huang <chii@fb.com>

Date:   Thu Nov 18 17:18:42 2021 -0800

    Build column lineage info from SELECT_LEX_UNIT, SELECT_LEX and TABLE_LIST

The last tested revision, preview-10.8-MDEV-13756-desc-indexes / c10e10c, has shown generally acceptable results, I think the feature can be merged into the main branch and released with 10.8.1 without a new round of tests, provided that the following issues are addressed:

• DESC key attribute becomes prohibited for CONNECT and SPIDER engines to avoid revealed problems leading to wrong results (MDEV-27591, MDEV-27590, MDEV-27581 and likely more);
• MDEV-27592 (InnoDB index corruption) gets fixed – I assume if the fix requires extra testing, it will be done within InnoDB team before the push;
• MIN/MAX optimization is not enabled before the release, but instead MDEV-27576 is targeted for 10.9+ (if any at all). If it is enabled, further testing will be definitely required.

There are other open bugs related to the feature, but I do not consider them blockers for the release. I expect most of them to be fixed before the GA though, so that we do not increase the amount of "known legacy issues".

I think the last [partially] tested revision, preview-10.8-MDEV-13756-desc-indexes / 1c4cbb946, can be pushed into the main branch and released with 10.8.1.

There are a few known issues remain, but they are not deemed critical for the initial release.
Examples (not an exhaustive list):

• fulltext search on tables with descending PK may misbehave (MDEV-27582),
• different direction of indexes on a Spider table and an underlying table should be avoided (MDEV-27633).

Due to existing legacy issues causing wrong query results, adding descending indexes to tables or converting ascending ones into descending sometimes bring different results comparing to what they were before. It happens because the change in the execution plan can trigger an old issue or, on the contrary, circumvent an old issue so that the result becomes correct while it was wrong before. These problems are usually reproducible even after replacing the use of the descending index with slight tweaks in query/schema/data, and thus need to be dealt with out of the scope of this task. Many of such legacy issues already exist in MariaDB bug tracking system, possibly there are more to be revealed. If in doubt whether it's a known problem or not, users should report the ones that they encounter.

I need this feature for INNODB, is there any version that already has it?
Are there plans to have it?

This was added to MariaDB Community Server 10.8. Any subsequent release series will also have the feature.

Be aware that `ORDER BY a DESC, b DESC` with `INDEX(a,b)` has always been supported – by scanning the index backward.

I think this is already optimized:
WHERE a=constant
ORDER BY a ASC, b DESC

The feature missing is when `ORDER BY` has multiple columns, but not in the same direction.

@Rick James, I tested on 11.0.3-MariaDB-log and 10.11.3-MariaDB-log, and as soon as I add DESC to b, it adds "using filesort" to explain and the query takes twice as much time.