The point is, to allow the system to boot and run normally without automating any un-tested changes.
I don't have your device/firmware combination so all I can do is give an example with made-up names.
Normal:
The initialization scripting (up-start) will, at some point, issue:
losetup /dev/loop/3 /our/protected/from/change/company/fonts.file
mount /dev/loop/3 /usr/java/lib/fonts.
The first translates a file into a storage device.
The second grafts the file system on that storage device into the system tree.
Now the folders and files contained inside of the squashfs file, fonts.file, appear to be (actually, are) part of the over-all file system tree.
The system continues to boot until normal completion.
One of the properties of an inode file system (both your Kindle and your MacOSx box) is this ability to use any existing directory entry in the tree to mount the file system contained on another backing store (which was done above).
Now what happens if you mount ANOTHER file system on a different backing store at the same (/usr/java/lib/fonts) mount point?
For new accesses, only the newest file system mounted (think, the 'top' one) can be seen by the rest of the system.
For any files open on the first ('bottom') one, the I/O continues to the original one (for more or less the same reason that you can still use a 'deleted' file if it was open before the delete).
So to get the system to start using the files in the new ('top') system you just over-mounted the old one with, you have to prod the system into closing all files that might have been open at the time.
Hence the 'restart cvm' step (it, or its children (anything 'Java')) are most likely the things that would have the old files either open or cached or both.
Also, it is my guess that all of the file system (a very basic thing) happened in the start-up sequence long before cvm was started.
I.E: restarting cvm will not trigger a file system tree creation that would wipe out your second mount (with a third)
.
Now, how do you do this 'change-over' script?
# You need to find the next available loop device:
nxt=$(losetup -f)
# You have to use that loop device to translate your new file into a device
losetup /var/local/my/new/fonts.new $nxt
# Then you have to mount the new device on top of the existing system at that mount point
mount -t squashfs $nxt /usr/java/lib/fonts
# Make cvm and its children let go of the old (now 'bottom') layer files
initctl stop cvm
# Get everything just stopped, re-started again
initctl start cvm
And put that into a manually executed (by you) script.
That way, only you can brick the device and you can un-brick it using the power button to force a re-boot.
If you had the initialization system use your un-tested font file automatically, you could only find errors by noticing that the Kindle had automatically bricked, with no way other than using the serial port to un-brick it.
The Kindle OS is traditionally super-sensitive to font files.
People who don't leave themselves an 'out' when changing font files around are putting the Kindle on a short path to suicide.
Note:
You would need to confirm each line of the above proposed script on the command line, just to be sure I got all the names correct and did not typo anything.
OH, .... not shown above, how to un-mount something:
umount /dev/loop/whatever number
and getting rid of a loop_device
losetup -d /dev/loop/whatever_number
Remember:
The 'man'(ual) command is your friend:
On a system with the manuals installed (or in your web browser search engine or your MacOSx termina, if your Mac supports the commands):
man losetup
man mount