I browsed over this issue 'actually looking up fonts on the system' issue #143 https://github.com/latex3/fontspec/issues/413, one less than 42! damn it, isnt's that the answer to Life, the Universe and Everything? lol That means that we're almost there. At least for these fonts' lookups under the greatest engines on planet earth. Anyway
Running two systems: one under texlive2023 and the other one under texlive2024. The one with the texlive2023 fontspec manual is dated 2022/01/15 v2.8a and the other one the most recent one, is dated 2024/02/13 v2.9a. Not surprisingly, nothing about the KpseOnly option is mentioned on the v2.28a version dated on 2022/01/15 precisely because the option KpseOnly was added after and even though the most recent one (v2.9a) mentions it, albeit very vague and superficial right on page 10 of that fontspec manual, there's not much more additonal info as to how is this optional argument implemented. On that issue https://github.com/latex3/fontspec/issues/413 and quoting Karl here «Yes, right. But ... as found by kpse, using the standard TeX-world paths, not involving system font paths (like /usr/share/fonts) or fontconfig (xetex). That is what I had always understood "filename lookup" to mean, as far as I understood it, and how the fontspec documentation talks about it. Thus it was news to me that luaotfload looks in the system font directories even when a filename is requested. For myself, I think this difference between xetex and luatex is undesirable. If it is kept as the default by fontspec, at least it should be documented and the [KpseOnly] option come back into play, so those of who need reproducible, system-independent documents can have them. We'll see what Will thinks (who mentioned to me he's busy at work so nothing will happen soon, anyway).» That's actually how I pretty much understood the file name lookup and the whole thing anyway. and then Will Robertson said «Thanks all for the discussion. I have to admit I’m leaning towards keeping the current behaviour simply for backwards compatibility, and allowing [OnlyKpse] to be a font option so you could write \defaultfontfeatures{OnlyKpse} in a fontspec.cfg file and change the behaviour globally for oneself. Anyone else like to weigh in on the relative merits of either approach?» Then the oustanding issue was finally merged on May 5, 2022 even though somewhere along between the release of 2023 and shortly after, some more changes took shape reflecting I presume, the aformentioned issue to have such an option as KpseOny. And there we go! The whole story repeated itself again with changing certain parts of the document to accomodate whatever the modifications that took effect and were coming from the engines. But I also remember that something happened. The Extension had to be thus, specified. Not so much as an option but also for every font or for the whole family such as {fontname.otf} or individually e.g one could have \setmainfont[whateveroption=font.extension]{font} or \setmainfont[whateveroption=font]{font.extension} Now both XeTeX (v3.14) and LuaTeX (v1.18) only undertand the path of system fonts such as /usr/share/ and /usr/local/share or whatever the path happens to be to find them. There's no room to have any engine work successfully for a lookup under kpathsea or wherever the variable texmflocal points to. Nope. not such a thing. --
