Hmm, that seems similar issue we've met with ibus cache:

$ rpm-ostree db diff
ostree diff commit from: rollback deployment (fbaac5f3877d7dc590a43948eb4c832b47d0a5e85a221dc6789bac161628e351)
ostree diff commit to:   booted deployment (51d39a14af65893fbdd0c8a21733c9f1f7ccf6826cc9c1dfaf3ddd825b4bebd9)
Added:
  glibc-langpack-hi-2.30-1.fc31.x86_64
  google-noto-sans-devanagari-ui-vf-fonts-20181223-6.fc31.noarch
  google-noto-sans-devanagari-vf-fonts-20181223-6.fc31.noarch
  hunspell-hi-1:1.0.0-12.fc31.noarch
  hyphen-hi-1:0.7.0-14.fc31.noarch
  langpacks-core-hi-2.0-6.fc31.noarch
  langpacks-hi-2.0-6.fc31.noarch
  samyak-devanagari-fonts-1.2.2-22.fc31.noarch
  samyak-fonts-common-1.2.2-22.fc31.noarch
$ diff -pruN <(ls --color=no -1 /sysroot/ostree/deploy/fedora-workstation/deploy/fbaac5f3877d7dc590a43948eb4c832b47d0a5e85a221dc6789bac161628e351.0/usr/lib/fontconfig/cache/ |sort) <(ls --color=no -1 /sysroot/ostree/deploy/fedora-workstation/deploy/51d39a14af65893fbdd0c8a21733c9f1f7ccf6826cc9c1dfaf3ddd825b4bebd9.0/usr/lib/fontconfig/cache/|sort)
--- /dev/fd/63	2019-09-12 15:16:02.848180258 +0900
+++ /dev/fd/62	2019-09-12 15:16:02.849180258 +0900
@@ -6,6 +6,7 @@
 210c0516121708a580e22e6b1f9a103a-le64.cache-7
 26078b1cf62d7535e9fc9c56a8803883-le64.cache-7
 2881ed3fd21ca306ddad6f9b0dd3189f-le64.cache-7
+30b9c3e04f780095e7cb0ae44a315810-le64.cache-7
 3830d5c3ddfd5cd38a049b759396e72e-le64.cache-7
 3c3fb04d32a5211b073874b125d29701-le64.cache-7
 3e9ca894d7ccd8b9fedb236c4f3f7c4e-le64.cache-7
@@ -30,6 +31,7 @@ b4d0b56f766d89640448751fcd18ec1e-le64.ca
 b887eea8f1b96e1d899b44ed6681fc27-le64.cache-7
 cf759820c416606818fc74e5e9991313-le64.cache-7
 d3379abda271c4acd2ad0c01f565d0b0-le64.cache-7
+d63f98f14a274bd69a5425fc33aaac6b-le64.cache-7
 df893b4576ad6107f9397134092c4059-le64.cache-7
 e26bf336397aae6fcef4d3803472adec-le64.cache-7
 e34b99a1e22e6f7451938fb9934274e6-le64.cache-7
$ strings /sysroot/ostree/deploy/fedora-workstation/deploy/51d39a14af65893fbdd0c8a21733c9f1f7ccf6826cc9c1dfaf3ddd825b4bebd9.0/usr/lib/fontconfig/cache/30b9c3e04f780095e7cb0ae44a315810-le64.cache-7 | grep ttf
/usr/share/fonts/samyak/Samyak-Devanagari.ttf
$ strings /sysroot/ostree/deploy/fedora-workstation/deploy/51d39a14af65893fbdd0c8a21733c9f1f7ccf6826cc9c1dfaf3ddd825b4bebd9.0/usr/lib/fontconfig/cache/d63f98f14a274bd69a5425fc33aaac6b-le64.cache-7 | grep ttf | head -1
/usr/share/fonts/google-noto-vf/NotoSansDevanagari-VF.ttf

Erm, difference must be three not two. one is a cache for /usr/share/fonts/samyak. one if a cache for /usr/share/fonts/google-noto-vf. and another one which apparently we are missing here is a cache for /usr/share/fonts.

That looks like a race again.

Hmm, actually this seems not race. because this happens even when installing one package. see:

$ rpm-ostree db diff
ostree diff commit from: rollback deployment (fbaac5f3877d7dc590a43948eb4c832b47d0a5e85a221dc6789bac161628e351)
ostree diff commit to:   booted deployment (798e14ea8bdc3ea82650996239a31d0bd0946575d019b832b393ded7d696f9ed)
Added:
  samyak-devanagari-fonts-1.2.2-22.fc31.noarch
  samyak-fonts-common-1.2.2-22.fc31.noarch
$ diff -pruN <(ls --color=no -1 /sysroot/ostree/deploy/fedora-workstation/deploy/fbaac5f3877d7dc590a43948eb4c832b47d0a5e85a221dc6789bac161628e351.0/usr/lib/fontconfig/cache/) <(ls --color=no -1 /sysroot/ostree/deploy/fedora-workstation/deploy/798e14ea8bdc3ea82650996239a31d0bd0946575d019b832b393ded7d696f9ed.0/usr/lib/fontconfig/cache/)
--- /dev/fd/63	2019-09-12 18:51:32.920178932 +0900
+++ /dev/fd/62	2019-09-12 18:51:32.921178932 +0900
@@ -6,6 +6,7 @@
 210c0516121708a580e22e6b1f9a103a-le64.cache-7
 26078b1cf62d7535e9fc9c56a8803883-le64.cache-7
 2881ed3fd21ca306ddad6f9b0dd3189f-le64.cache-7
+30b9c3e04f780095e7cb0ae44a315810-le64.cache-7
 3830d5c3ddfd5cd38a049b759396e72e-le64.cache-7
 3c3fb04d32a5211b073874b125d29701-le64.cache-7
 3e9ca894d7ccd8b9fedb236c4f3f7c4e-le64.cache-7

The above newly created cache is for /usr/share/fonts/samyak. we're still missing one more updates here.
Updating the cache for /usr/share/fonts failed somehow. I don't know what exactly happened during the package installation. need some comments from ostree guys. so reassigning to ostree so far.

Hmm, sorry, it wasn't accurate. trying again...

Okay, got it. moving back to fontconfig.

Please make sure if you don't have fontconfig caches on $HOME/.cache/fontconfig. that prevents using updated system caches because ostree resets the mtime to @0.

I was hitting this, and I can confirm that deleting the fontconfig cache in $HOME/.cache/fontconfig was sufficient to get the new fonts to show up.
But the cache files in my home directory were regenerated immediately afterwards, so presumably this issue will be seen again any time system fonts are changed (regardless of whether they're part of the base image or installed with rpm-ostree).

Yes, see https://github.com/fedora-silverblue/issue-tracker/issues/28#issuecomment-579103999 for more details. for 2) I've applied a patch to fontconfig in rawhide so that it can read the latest caches anyway.

We may need to take some actions for 1 and 3 in ostree or workaround in fontconfig in case of ostree-based distro. reassigning again to ostree for some feedback on it.

Still seeing this issue on even f32 and decided to have a workaround for this issue in fontconfig.

Basically we won't see any changes against system files on Silverblue without reboot. so we can consider system caches for system fonts is always latest even if we have user caches for system fonts by fc-cache -f.

Because of that reason, I've patched fontconfig out to ignore non-zero timestamped caches for zero timestamped directories and fonts.

FEDORA-2020-c710e5c2c9 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-c710e5c2c9

FEDORA-2020-c710e5c2c9 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c710e5c2c9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c710e5c2c9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-c710e5c2c9 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

I think this issue still persists, in some form, with fontconfig-2.13.92-9 on Fedora 32. I have a number of manually installed fonts in /usr/share/fonts and generally run 'sudo fc-cache -fsv' to update the font cache. I don't quite remember the exact sequence of events, but I think at one point a few weeks ago I only ran 'fc-cache -fv' (which would have generated font caches in the user's home directory, if I understand correctly). At this point, I discovered that certain fonts were not available to the system and wouldn't appear in the list produced by 'fc-list', though running 'sudo fc-cache -fsv' would make all fonts available again. This would not persist after shutting down, though, and on the next boot some fonts would be unavailable again.

Deleting the cache files in ~/.cache/fontconfig/ seemed to make all installed fonts immediately visible again, and the fix seems to persist across reboots.