Upgrade of libapache2-mod-php8.1 does not reload apache2

Today we discovered that most of our servers that are running Apache2 + libapache2-mod-php had Apache2 running with an older version of PHP, even though libapache2-mod-php(7.4|8.1) was updated.
After investigating, we found that libapache2-mod-php8.1 uses a trigger to reload apache, but that this is not supported in the apache2-maintscript-helper script.

The expected behavior is that after upgrading or reinstalling libapache2-mod-php8.1, Apache2 is restarted. This should be visible by looking at the start time of the apache2 process in the process list.

As far as we could find, the problem exists in apache2-maintscript-helper ( https://git.launchpad.net/~agogo147/ubuntu/+source/apache2/tree/debian/debhelper/apache2-maintscript-helper?h=applied/debian/bullseye#n221). When the trigger from libapache2-mod-php8.1 runs, the apache2-maintscript-helper is executed with the following variables:

APACHE2_MAINTSCRIPT_NAME=postinst
APACHE2_MAINTSCRIPT_METHOD=triggered
APACHE2_MAINTSCRIPT_ARGUMENT=/etc/php/7.4/apache2/conf.d

That means that the apache2_needs_action function returns 1 (e.g. no action necessary) so the intended reload does not happen.

Output of the trigger of a reinstall of libapache2-mod-php7.4 with APACHE2_MAINTSCRIPT_DEBUG=1 set in envvars:

Processing triggers for libapache2-mod-php7.4 (7.4.3-4ubuntu2.19) ...
+ APACHE2_MAINTSCRIPT_DEFER=
+ + egrep -q installed|triggers-awaited|triggers-pending
dpkg-query -f ${Status} -W apache2
+ [ -z triggered ]
+ APACHE2_MAINTSCRIPT_NAME=postinst
+ [ postinst ]
+ APACHE2_MAINTSCRIPT_PACKAGE=libapache2-mod-php7.4
+ [ -z libapache2-mod-php7.4 ]
+ [ -z ]
+ APACHE2_MAINTSCRIPT_METHOD=triggered
+ [ -z ]
+ APACHE2_MAINTSCRIPT_ARGUMENT=/etc/php/7.4/apache2/conf.d
+ [ triggered = triggered ]
+ [ /etc/php/7.4/apache2/conf.d = /etc/php/7.4/apache2/conf.d ]
+ [ -e /usr/share/apache2/apache2-maintscript-helper ]
+ . /usr/share/apache2/apache2-maintscript-helper
+ [ -n 1 ]
+ return
+ apache2_reload restart
+ apache2_needs_action
+ [ triggered = configure ]
+ return 1
+ return 0
+ exit 0

Although I would be highly surprised if this is actually an issue that has not been reported yet, I could not find any reports mentioning this behavior. Also, there's a security element to this: we expected the package upgrades (we're running unattended updates) to ensure the PHP version we're running is uptodate, but now it turns out we're running old versions of PHP without us knowing.