When I set "When laptop lid closed: Sleep" in KDE on my Dell Latitude 7390, plugging or unplugging the AC power also triggers Suspend to S3. Unsetting that option stops the undesired Suspending. Setting hw.acpi.lid_switch_state=S3 makes the lid switch trigger S3 but does not trigger this issue, so the problem does not seem to be caused by an errant ACPI Lid Switch message. I managed to debug this as far as determining that the suspend request is coming via ConsoleKit but I don't know how to debug it beyond that point.
Further debugging determines that upowerd is responding to Get LidIsClosed messages with "true". And I just noticed an interesting pattern: After I first boot the system, I can plug/unplug AC power without triggering S3. The AC-power-triggers-S3 behaviour only starts after I close the lid for the first time. Maybe upowerd is getting a "lid closed" message but not a "lid open" message and so it's remembering the "closed" state and replying with it long after the lid is reopened...
Aha! It's an ACPI issue. If my laptop is suspended when I open the lid, it unsuspends but does not send a "Lid Opened" ACPI notification. As a result, devd does not send a "Lid state changed" message, and upowerd does not update its notion of whether the lid is open or not. This actually causes two issues: 1. As noted before, if upowerd thinks that the lid is closed, plugging/unplugging AC power results in KDE suspending the system. 2. If upowerd thinks that the lid is already closed, closing the lid *doesn't* result in KDE suspending the system. So in addition to the unexpected suspends from the AC power state changing, closing the lid was only making KDE suspend the system every 2nd time. I'm reclassifying this as "base system" and assigning to myself -- I think I can see how to fix this in acpi_lid.c.
A commit references this bug: Author: cperciva Date: Sat May 16 01:50:28 UTC 2020 New revision: 361097 URL: https://svnweb.freebsd.org/changeset/base/361097 Log: Send Lid status notification via devd from acpi_lid_status_update. Some laptops don't send ACPI "lid status changed" notifications upon opening the lid if the system was currently suspended. In r358219 this was partially fixed, updating the "lid_status" variable upon resume even if there is no "status changed" notification from ACPI. Unfortunately the fix in r358219 did not include notifying userland via devd; this causes problems on systems using upowerd (e.g. KDE), since upowerd remembers the most recent devd notification about the lid status rather than querying the sysctl to get the current status. This showed up as two symptoms when KDE's "When laptop lid closed: Sleep" option is set: 1. 50% of the time, closing the lid would not trigger S3 sleep. 2. 50% of the time, plugging/unplugging AC power would trigger S3 sleep. PR: 246477 MFC after: 3 days Changes: head/sys/dev/acpica/acpi_lid.c
A commit references this bug: Author: cperciva Date: Tue May 19 01:39:38 UTC 2020 New revision: 361234 URL: https://svnweb.freebsd.org/changeset/base/361234 Log: MFC r361097: Send Lid status notification via devd from acpi_lid_status_update. Some laptops don't send ACPI "lid status changed" notifications upon opening the lid if the system was currently suspended. In r358219 this was partially fixed, updating the "lid_status" variable upon resume even if there is no "status changed" notification from ACPI. Unfortunately the fix in r358219 did not include notifying userland via devd; this causes problems on systems using upowerd (e.g. KDE), since upowerd remembers the most recent devd notification about the lid status rather than querying the sysctl to get the current status. This showed up as two symptoms when KDE's "When laptop lid closed: Sleep" option is set: 1. 50% of the time, closing the lid would not trigger S3 sleep. 2. 50% of the time, plugging/unplugging AC power would trigger S3 sleep. PR: 246477 Changes: _U stable/12/ stable/12/sys/dev/acpica/acpi_lid.c