The file should be created with root:utmp ownership regardless of the GID. Is that not what you're seeing?

Yes, this is indeed true for /var/run/utmp.

In order to work, libutempter requires /usr/lib/utempter/utempter to be owned by root:utmp. However, specifying root:utmp ownership for a file in the PKGBUILD does not mean that this file is indeed owned by root:utmp if the GID of utmp on the local system and the GID of utmp on the building system differ. If on the building system the GID of utmp is 20, then mtree contains "gid=20" [1] and this is the GID that the file obtains when pacman installs it. If on the local system the GID of utmp is also 20 then the owner is root:utmp. If, however, the GID of utmp on the local system is not 20, then the file is installed with owner root:20. Setting non-root group ownerships in PKGBUILD is only safe if it is guaranteed that the respective group exists AND has the same GID on every potential system that installs the package. Otherwise, the group name in PKGBUILD is meaningless.

This can easily be tested: Create the group "testgroup" and a PKGBUILD that sets ownership of a file to root:testgroup. Let's assume that the GID of testgroup is 999. Then install the package in the following two scenarios:
- Keep the group testgroup and install the package. The file is installed with the owner root:testgroup.
- Remove the group testgroup and install the package. The file is installed with the owner root:999.

Because on the building system the GID of utmp is 20, the file /usr/lib/utempter/utempter is always installed with root:20 ownership by the libutempter package. Whether 20 matches the GID of utmp on the local system is irrelevant. In the latter case, the group ownership of /var/run/utmp and /usr/lib/utempter/utempter differ and libutempter does not work.

[1] zgrep -w -e 'uid=[1-9][0-9]*' -e 'gid=[1-9][0-9]*' /var/lib/pacman/local/libutempter-1.1.6-2/mtree yields
./usr/lib/utempter/utempter time=1382669529.510785838 mode=2755 gid=20 size=10192 md5digest=e44da906c040fd638192d66dc97ba41c sha256digest=7828f9699468468b3ce3e068c5b07068bbb5f86286a1af14d5d13136de4e053e

So this has nothing to do with /run/utmp, but /usr/lib/utempter/, which just needs a systemd-tmpfiles entry.

Yes although that will mean pacman -Qkk will detect /usr/lib/utempter/utempter as having changed ownership.

I reached here because I couldn't get wall messages in KDE. In my Arch Linux box this yields the following at the moment:

zgrep -w -e 'uid=[1-9][0-9]*' -e 'gid=[1-9][0-9]*' /var/lib/pacman/local/libutempter-1.1.6-3/mtree
./usr/lib/utempter/utempter time=1528120616.0 mode=2755 gid=996 size=9992 md5digest=2c1dc57a2bda7273bbfad1458f9ff6b7 sha256digest=6a306a964f851ec89bfc5ab3031982a8c63d21017bf0d2f258d2f4fbd65fccfa

However my utmp group looks like this:
$ getent group utmp
utmp:x:20:

NOTE: My Arch Linux was installed around 2015 December and only upgrades are being applied since then.
I manually changed "/usr/lib/utempter/utempter" to be in utmp group and now wall messages are captured by KDE's "Write Daemon" and I got notifications on wall messages.

$ stat /usr/lib/utempter/utempter
File: /usr/lib/utempter/utempter
Size: 9992 Blocks: 24 IO Block: 4096 regular file
Device: fe02h/65026d Inode: 1363129 Links: 1
Access: (2755/-rwxr-sr-x) Uid: ( 0/ root) Gid: ( 20/ utmp)
Access: 2019-02-21 09:36:57.269891247 +0200
Modify: 2018-06-04 16:56:56.000000000 +0300
Change: 2019-02-08 16:54:34.691014319 +0200
Birth: -

Actually, I also get an error when building the package with 'staging-x86_64-build' in a chroot:
chown: invalid group: ‘root:utmp’
==> ERROR: A failure occurred in package().

with arch-chroot, more /etc/group, I get:

root:x:0:root
builduser:x:985:

Switch to using tmpfiles.d to change the permissions and ownership of /usr/lib/utempter/utempter.

Can loqs's diff please be merged and the libutempter package rebuilt? This issue is making it appear that tmux, xterm, etc. are broken as well as other things that rely on utmp to determine currently logged in interactive users.

My /usr/lib/utempter/utempter's group is dnsmasq, and I see other strange groups like git or systemd-journal-remote on other Arch systems. I've used a hook to update the file's permissions.