Update to description of problem:

My present workaround to apply some direct formatting to the number (and exclusively to the number, not impacting item text) is to select the paragraph mark of the target item.

This works only if _Character style_ for this level is set to _None_.

But, after more experimentation, I discovered that _Bullet_ "numbers" will not react to the workaround, making impossible to individualise an item bullet.

_Graphics_ "numbers" also don't react but this can be expected. All other "numbers" can receive direct formatting (again, only if character style is None, which is a divergence from the usual precedence CS < DF for all other attributes)

Another addition to the issue:

The direct formatting trick is either impossible or does not survive the session if the list item contains line breaks or cross-references (this seems irrelevant, but as soon as the list item is "complex", the trick is ineffective).

NOTE. The formatting add to list numbers isn't visible in older versions of LibreOffice. 

Like 
Version: 7.4.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 30a048cb895a3dcdd6048f3c525edd95a1371b91
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

or
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

Direct formatting bypassing list bullets or numbers is expected, for when the user selects several paragraphs at once (the bullets/numbers being inside the selection) and changing the direct formatting. I think most users would expect this to only affect the text and not the bullets/numbers.

Regardless, you are here talking about a case when the selection only includes the bullet. I can see your method in https://ask.libreoffice.org/t/direct-formatting-of-list-symbols/99731/7 requires the user to have a selection of _the next_ bullet/number in order to change the direct formatting of a bullet/number.
The first thing to do is sort out this oddity of having to select a different thing to what we want to change, in bug 158879.

Anyway, reproduced in recent trunk build: changing the marker's character style from "Numbering Symbols" to "None" in the sample's 3rd list restores the green colour.

(In reply to Stéphane Guillou (stragu) from comment #4)
> Regardless, you are here talking about a case when the selection only
> includes the bullet. I can see your method in
> https://ask.libreoffice.org/t/direct-formatting-of-list-symbols/99731/7
> requires the user to have a selection of _the next_ bullet/number in order
> to change the direct formatting of a bullet/number.
> The first thing to do is sort out this oddity of having to select a
> different thing to what we want to change, in bug 158879.

After thinking about it, it is not that odd. What you select in fact is the paragraph marker. It belongs in the current list item (it is the last "component" of the paragraph). Therefore, "logically", you are still inside the list item you want to change, even if you select something "at the other end".

What is confusing (even for somebody versed in Writer subtleties), is teh necessity to select also the next list number (which does not happen when you want to process the last item in a list because the next paragraph is "normal"; it also means you must create an extra paragraph if the list item is the last paragraph in a document) because the list number is a Writer-generated piece, not something explicitly entered by user. And this gives the illusion you select something in the next paragraph.


> Anyway, reproduced in recent trunk build: changing the marker's character
> style from "Numbering Symbols" to "None" in the sample's 3rd list restores
> the green colour.

This is where the bug lies. DF precedence over character style is observed for all attributes, except colour. This means you can't play with both character style and DF for spot modification. This breaks the usual behaviour PS < CS < DF. This precedence should be restored for colour and afterwards we'll evaluate to see if this solves the problem without introducing others.

I think the request is rather exceptional that most users won't ever be aware of the possibility. So, the selection peculiarity could be left aside it too difficult to improve.

Version: 25.8.4.2 (X86_64)
Build ID: 580(Build:2)
CPU threads: 4; OS: Linux 6.17; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded

Situation is now even worse: the workaround no longer achieve the desired result; it is ineffective.

Looking at the XML, direct formatting for item number is in a <text:span …/> element (preceding </text:p>) tagging an empty sequence of text. Perhaps a more consistent handling of such empty elements is responsible for deleting workaround effect.

We can no longer "individualise" item numbers.