There are plenty of options for running a script of your choice on power and lid events, so this shouldn’t be hard to accomplish, yeah, no kernel programming needed.
The hard part is not conflicting with everybody else who thinks they should drive the computer: if systemd thinks it owns power events, and GNOME thinks it owns power events, and acpid thinks it owns power events… it’s a mess, especially if e.g. you want things to work both on a kernel console and in a desktop environment—or maybe even in more than one.
At some point my old laptop would occasionally wake up and immediately go back to sleep again, because two services were racing to put it in suspend and one of them winning did not kill the other. Then it stopped doing that. And I had to give up on figuring what part of the GNOME monolith was responsible for that mess. (At this rate, I’m going to have to give up on GNOME itself because of all this opaqueness, but I don’t wanna…) And I could never get it to wake up reliably if I closed the lid and opened it back again too quickly.
Fundamentally, the problem seems to be that lid, power, etc. events are edge- rather than level-triggered, that is, the question is not “the lid is currently closed, what state do we want the system to be in?”, but “the lid just closed, what do we do?” That’s just a bad approach in general, but other systems can get away with it because they have much less software diversity than the Linux ecosystem (which obtains most of its value from that diversity).
Sorry for the rant. TL;DR is you should be able to patch this over with a script, but the most reliable approach is likely to be figuring out what responds to lid and power events on your system, then tracking down its developers and slapping them with this bug (gently) until they fix it. Or at this point you might as well fix it yourself.