According to the thread rooted here:

https://tug.org/pipermail/tex-live/2019-May/043690.html

updates to lualibs and luaotfload were uploaded to CTAN a couple of weeks ago.  The changes to luaotfload can be seen here:

https://github.com/u-fischer/luaotfload/blob/master/NEWS

but none of them really jump out at me as being likely to be related to this bug report.

If I run lualatex over the test.tex file shown above on my Fedora 30 machine, to generate the font cache, then I see this:

$ luaotfload-tool --find lmroman12-regular
luaotfload | resolve : Font "lmroman12-regular" found!
luaotfload | resolve : Resolved file name "/usr/share/texlive/texmf-dist/fonts/opentype/public/lm/lmroman12-regular.otf"

If I then copy the luatex-cache directory from the Fedora 30 machine into a Rawhide mock chroot, running that same command inside the mock chroot does this:

$ luaotfload-tool --find lmroman12-regular
luaotfload | db : Version mismatch; expected -1, got 5.
luaotfload | db : Force rebuild.
luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: "Font lmroman12-regular not found.".
luaotfload | resolve : sequence of 3 lookups yielded nothing appropriate.
luaotfload | resolve : Cannot find "lmroman12-regular" in index.
luaotfload | resolve : Hint: use the --fuzzy option to display suggestions.

That's interesting.  Why is version -1 expected?  That message seems to be coming from /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua, where -1 is the value of names.version.  Is that the "names" defined on line 204?  I've never gotten around to learning lua. :-(

The version -1 thing appears to be a red herring.  On Fedora 30, /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua has this at line 3683:

        names.version   = 5        --- increase monotonically

but the Rawhide version has this instead, at line 3741:

        -- MK Changed to rebuild with case insensitive fallback.
        --    Negative version to indicate generation by modified code.
        names.version   = -1       --- decrease monotonically
        -- /MK

so apparently that was deliberate.

The function read_font_names, line 1815 of /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua, always reports 0 new fonts.  I turned on some logging, and see this:

luaotfload | db : Scanning 426 collected font files ...
luaotfload | db : Loading font ..ts/opentype/public/lm-math/latinmodern-math.otf
luaotfload | db : Failed to read basic information from "latinmodern-math.otf": "the file cannot be opened for reading"
luaotfload | db : Loading font ..ts/opentype/public/lm/lmromancaps10-oblique.otf
luaotfload | db : Failed to read basic information from "lmromancaps10-oblique.otf": "the file cannot be opened for reading"
luaotfload | db : Loading font ../fonts/opentype/public/lm/lmroman17-regular.otf
luaotfload | db : Failed to read basic information from "lmroman17-regular.otf": "the file cannot be opened for reading"
...

This indicates that read_font_file always returns false, due to some problem opening files for reading.  Some extra logging added by yours truly shows that calls into readers.getinfo on line 2455 of /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua.  That in turn indicates that loadfont returned nil.  Here are the last few lines of the loadfont function:

    local ok, result = xpcall(loadfontdata,message,specification)
    if ok then
        return result
    end
--     return loadfontdata(specification)
end

If I change that xpcall into a direct "loadfontdata(specification)", I see this:

luaotfload | db : Scanning 426 collected font files ...
luaotfload | db : Loading font ..ts/opentype/public/lm-math/latinmodern-math.otf
...texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua:2036: attempt to call a nil value (upvalue 'stripstring')

Here is the line in question:

       local tag      = lower(stripstring(readstring(f,4)))

And there is our problem: stripstring is not defined.  This is line 79 of /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua:

local stripstring       = string.nospaces

where, in contrast, this is what that line reads in the Fedora 30 version of the file:

local stripstring       = string.strip

If I change it back to string.strip, then the next run shows this:

luaotfload | db : Scanning 426 collected font files ...
luaotfload | db : Loading font ..ts/opentype/public/lm-math/latinmodern-math.otf
...texmf-dist/tex/luatex/luaotfload/fontloader-font-otr.lua:1041: attempt to call a nil value (field 'to16dot16')

That line reads as follows:

           fontversion       = number.to16dot16(fontversion),

I see that /usr/share/texlive/texmf-dist/tex/luatex/luaotfload/fontloader-reference.lua has definitions of both string.nospaces and number.to16dot16.  Why doesn't fontloader-font-otr.lua have them?

So fontloader-font-otr.lua doesn't have those functions because they are defined in lualibs 2.64.  The version in texlive-lualibs is too old; it does not define those functions, and possibly others.  If texlive-lualibs is updated, everything should magically work again.

Good detective work. texlive-2018-26.fc31 is building now with the latest lualibs.

Everything else in texlive also needs to be updated, but I haven't had enough time to do that yet.

I'm not surprised.  That's got to be a huge job.  You have my sympathy.

texlive-2018-26.fc31 is built in rawhide. Please retry.

That does indeed fix the luatex issue.  Sadly, I have now hit some other issue, namely this:

./language.tex:59: Undefined control sequence.
<argument> ...x \ifdim \paperheight >0pt\relax \pdfpagewidth 
                                                  =\paperwidth \pdfpageheigh...
l.59 \begin{document}
                   
? 
./language.tex:59: Emergency stop.


That looks a lot like https://tex.stackexchange.com/questions/315025/lualatex-texlive-2016-standalone-undefined-control-sequence, but standalone.sty is not in use in this case.  The \pdfpagewidth control sequence does not appear in the PVS sources.  I see the following files in my mock chroot's /usr/share/texlive that contain the above sequence of tokens:
- texmf-dist/tex/latex/graphics-def/xetex.def
- texmf-dist/tex/latex/graphics-def/pdftex.def

Since the input file in question does not load xetex.def, I conclude by process of elimination that it is complaining about pdftex.def.

Incidentally, speaking of standalone.sty, the version in Rawhide in 0 bytes long.  That doesn't seem right.  Searching for
0 byte files also turns up /usr/share/texlive/licenses/collection.txt.

I think *this* bug is fixed.  If you like, I can file new bugs for whichever of the above seem worth filing bugs over.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.