Exercise 2: Why 40_custom, Not a Direct Edit to grub.cfg — Possible Solution
====================================================================

Explanation:

The chapter's own compare-table draws exactly this distinction based
on how grub-mkconfig treats each file. grub.cfg itself is entirely
REGENERATED from scratch every time grub-mkconfig runs -- it is
purely an OUTPUT file, built fresh each time from the numbered
scripts in /etc/grub.d/ and the settings in /etc/default/grub, with
no memory of whatever content it held previously. Anything typed
directly into grub.cfg is simply discarded the next time that
regeneration happens, exactly the mistake grub1-2 warned about.

40_custom, by contrast, is one of the numbered scripts INSIDE
/etc/grub.d/ itself -- it's treated as a genuine INPUT to the
generation process, not output. Per the chapter's own description,
grub-mkconfig runs 40_custom's own content as-is, folding it directly
into the newly generated grub.cfg each time, rather than trying to
auto-generate or overwrite whatever was placed there. Because
40_custom is part of the actual source of truth (alongside
/etc/default/grub), anything added there is preserved across every
future regeneration, the same durability property /etc/default/grub
itself has -- which is exactly why it's the correct place for a
genuinely custom, hand-written menu entry.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the input-vs-output distinction directly (grub.cfg is
regenerated output; 40_custom is a preserved input script) rather
than just restating "one survives and one doesn't" without explaining
the underlying mechanism.