I want to teach them the correct method and why it's correct.
There are multiple "correct methods". Some Linux distributions prefer configuration style, others prefer another, and someone else's system may have a different one installed. In most situations, "whatever the system currently uses" is the most correct method, but installing a different method out of preference or out of some specific requirement is not incorrect either.
/etc/network/interfaces belongs to Debian's "ifupdown" software and is used by the ifup and ifdown commands, or the networking and ifup@eth0 services. It's what you find on a fresh, "stock Debian" installation. (It can also be found in Alpine's ifupdown-ng with similar though very slightly different usage.)
Ifupdown is the traditional Debian mechanism, but I've always thought it's a bit flimsy (e.g. if an 'ifup' fails halfway, the result is that you can neither ifup nor ifdown the interface).
Still, if the system currently uses ifupdown, then editing /etc/network/interfaces is correct for that system.
To apply changes, either restart the ifup@<iface_name> service if it was defined as a hotplug interface, or the networking service otherwise – if I remember correctly.
NetworkManager is most commonly found on systems that have a GUI (e.g. GNOME or KDE), although it is not unsuitable for purely-CLI headless systems either, e.g. RedHat/Fedora likes to use NM in all situations.
On non-GUI systems, NM can be configured through nmcli con[nection] or nmtui, the latter being a full-screen form-based tool that's similar to the GUI ones. After editing a profile, changes will only take effect once you activate it again (e.g. nmcli con up <name>).
(Or even by directly editing its profiles in /etc/NetworkManager/system-connections and then 'nmcli con reload' and of course 'nmcli con up' the profile again… though beware that some fields are differently named in the raw files than they are in nmcli.)
Systemd-networkd comes built-in with any systemd-based distribution, though isn't necessarily active. Use networkctl to see whether there are any interfaces currently managed by networkd.
It's a good choice for Ethernet, somewhat less so for Wi-Fi (as it can't connect to Wi-Fi on its own and relies on manual iwd/wpa_supplicant configuration already being there).
Differently from NM, all changes to your networkd configuration take effect immediately upon networkctl reload.
Netplan(.io) is Ubuntu's invention, though it can also be used on any other system. It doesn't actually configure the network directly – instead it configures systemd-networkd (or NetworkManager), i.e. Netplan is basically a translator from YAML to networkd .network files (or NM profiles). As a result, most of Netplan's parameters are very similar to the ones in networkd, only the overall syntax is different.
So if you see systemd's networkctl showing a managed interface, but you can't find its .network file – or networkctl status eth0 says that the file is in /run – then it's likely to be Netplan-managed and you should check the netplan command next.
But if the system currently uses Netplan, then of course you should be editing the Netplan configuration, not the networkd one, and using netplan apply to re-generate and apply the changes (Although networkctl can still be used to check the current status.)
Other options may exist. Sometimes people use dhcpcd to configure even static parameters – it can do that despite primarily being a DHCP client.
You've missed another important method: configuring a static DHCP lease on the router, and letting the Pi use DHCP as it currently does. Sometimes that's preferable, sometimes it has downsides.
(On a router that has convenient DHCP lease management, it can be useful to use that as your IP address management method – you don't need to look for dynamic IPs in one place, static ones in another Excel table. But many home routers just don't do static DHCP leases at all.)
However, blindly choosing method that wasn't in use – e.g. editing /etc/network/interfaces "because that's what Debian uses" when it turns out that NetworkManager was actually in use on the system – will likely lead to problems and conflicts, even if the same method would've been "correct" on another system.
The real correct method is to investigate first – look at what's currently happening on the system, not to go blindly. For example, look at the list of services to determine if NM is running, or systemd-networkd is in use, etc.
On a similar note, after you think you've configured a static IP address, check the current status (using e.g. ip addr) to see whether the configuration has been indeed applied.
(This also includes the concept of checking journalctl -S -1h when something doesn't work, etc. A good chunk of questions on this site go like "I tried starting it 5 times and it's still not running" "Did you check the logs" "No" and it turns out that the system logs directly had the answer.)
