No graphics glitches with this kernel, and so far no hung boots. Too early to tell if hung boots issue is solved given that it only happens once in a while, but I will be optimistic and will try (again) marking this issue as solved.

If I don't post again, it's because the hung boots went away.

Since this issue may be related to kernel 3.16 and all of 4.9, 4.13, and 4.14 were giving me graphics artifacts, I'll try my luck with 4.15 and will report back.

The interesting bit is "intel_do_flush_locked failed: Invalid argument" of course. I did some duck-ducking and it sounds like this could be a kernel bug. If so, this is extremely strange because I'm running the same kernel in ascii that I was running in jessie without any issues (I'm using the older kernel 3.16.51-3+deb8u1 because ascii's default kernel causes some graphics artifacts on my machine: https://dev1galaxy.org/viewtopic.php?id=1905).

1. sudo apt-get install xinit (the xinit package contains the startx executable)
2. sudo apt-get purge lightdm
3. In /etc/inittab, comment out this line: 1:2345:respawn:/sbin/getty 38400 tty1
4. In /etc/inittab, add this line for autologin: 1:2345:respawn:/bin/login -f bruno tty1 </dev/tty1 >/dev/tty1 2>&1 (use your username instead of bruno, of course)
5. To run startx automatically upon login, add startx to ~/.profile

Hopefully the miscommunication between X and display manager (i.e., X sending a signal that it is ready for lightdm/slim to connect when it isn't actually ready) does not happen between X and startx. I'll mark as solved for now. If problem recurs I'll post again and remove the "solved" tag.

I'm giving up on getting X and a display manager to consistently play nice. Will try my luck with startx, hopefully it will be more consistent.

I also thought of downgrading X to the version from Devuan Jessie, which apparently never signaled before it was actually ready for incoming connections. I'm trying the downgrade now but am quickly finding myself in dependency hell.

If you would have a side entrance (eg ssh) ot the system you could check up if it might be this situation.

But I don't really know what to do about it. If any part of this is scripted, eg lightdm, it might be possible to insert a delay between receiving the ready signal and attempting a connection. Or something.

So a recap of where I am at this point:
1. Tried using slim instead of lightdm, but problem recurred so I'm back on lightdm.
2. Uninstalled consolekit. Problem recurred afterwards but I'm leaving consolekit uninstalled since it seems superfluous.
3. Ran pam-auth-update as root. Everything is checked in the prompt.
4. Did full system upgrade again this morning.

I'll update the thread when I have something new to share.

I tried uninstalling elogind (to simulate the package lineup in my problem-free Devuan Jessie partition) but doing so would force the removal of a truckload of packages including most of MATE. Therefore, I uninstalled consolekit. So far no negative consequences and I've booted my system 20 times for testing without any "hung" boots so far (using lightdm from ascii's repo). Fingers crossed...

fsmithred, is it possible that the intermittent nature of my issue was because of a race condition between elogind and consolekit?

I honestly know very little about these packages, so don't know why these particular ones are installed.

I don't have a clear grasp of the specifics but I do know that different display managers require different backends.  And an upgrade creates more problems than a new install. It has to do with the replacement of udev with eudev.  This post might shed some light on your problem.  fsmithred is one of the best sources for specifics.

Packages with 'libpolkit' in name:
libpolkit-agent-1-0:amd64 0.105-18+devuan2.4
libpolkit-backend-1-0-elogind:amd64 0.105-18+devuan2.4
libpolkit-gobject-1-0-elogind:amd64 0.105-18+devuan2.4
libpolkit-qt-1-1:amd64 0.112.0-5
libpolkit-qt5-1-1:amd64 0.112.0-5

Packages with 'consolekit' in name:
consolekit 0.4.6-6

Packages with 'elogind' in name:
elogind 234.4-1+devuan1.5
libelogind0:amd64 234.4-1+devuan1.5
libpam-elogind:amd64 234.4-1+devuan1.5
libpolkit-backend-1-0-elogind:amd64 0.105-18+devuan2.4
libpolkit-gobject-1-0-elogind:amd64 0.105-18+devuan2.4

I honestly know very little about these packages, so don't know why these particular ones are installed.

These are the only packages on my Devuan Jessie partition, which always boots reliably:

Packages with 'libpolkit' in name:
libpolkit-agent-1-0:amd64 0.105-9+devuan1
libpolkit-backend-1-0:amd64 0.105-9+devuan1
libpolkit-gobject-1-0:amd64 0.105-9+devuan1
libpolkit-qt-1-1 0.103.0-1

Packages with 'consolekit' in name:
consolekit 0.4.6-5

Packages with 'elogind' in name:
none

Which libpolkit packages are installed?
consolekit or elogind?
Is libpam-elogind installed?

I have no idea why it would be intermittent.