Can I work on this feature?

Yes, of course, you can.
Although, at the moment it does not look very likely that we will merge it — this MDEV is an idea of a feature, but it'd be good to know more about actual use cases, real world users asking for it for their real world applications, you know, some practical justification for adding it. As of now it doesn't look like a feature that users will actually use.

But if you just want something to practice — this is a good one, indeed.

Can you please make sure that this function is usable for a generated column?

f_razzoli, could you please describe your use case? How do you plan to use this function?

I already recommend customers to use the UUID type as a primary key. I noticed that some customers add a second UUID column that changes every time a row is updated. I don't know the reason.

I'll recommend to use UUID7 when it's in an LTS branch, because it doesn't require MariaDB to shuffle the bits under the hood.

Also, typical tables have timestamp columns like inserted_at and updated_at. Seems to me a good idea to "link" them to the UUID's, to ensure that if col_uuid changes col_timestamp will change and vice versa. It can also be useful to select recently changed rows from a table that doesn't have timestamps.

"doesn't require MariaDB to shuffle the bits under the hood" doesn't sound like an argument to me, why would anyone care what MariaDB is doing under the hood? I expected people to use UUID7 mainly for compatibility with other applications. UUIDv1 has better temporal resolution, one can generate them with a higher rate.

Anyway, okay, this sounds like a possible use case. Additionally, I think, this new function can also extract time part from UUIDv1, that fits into your use case too.

Okay, I'll come back to this later. For now, I'll focus on major priority issues.