Prior to 367.35, I had (most recently) been running 346.96 -- and resume worked. This was under stable/10, stable/11, and head (all amd64 -- all the same physical hardware; different slices of boot drive).
I realize that not everyone needs suspend/resume to work, but the machine in question is my laptop, and I carry it in my backpack as I cycle between home and the shuttle stop (as part of my commute to & from work). Having the laptop "on" and cooking itself in the backpack isn't a reasonable option, and powering it off is ... well, a regression, at best.
Might it be worthwhile to create an x11/nvidia-driver-346, pending a fix for the newer version of the driver?
(I have verbose dmesg.boot for the above 3 versions of the OS available, as well as a fair amount of other info, should that be wanted. And I'm happy to test.)
I just tried downgrading to x11/nvidia-driver-340; that seems to work (including suspend/resume), at least under stable/11.
Just FYI, removing driver "device VESA" (included in GENERIC) from the kernel config, switching to sc console and building + installing the new kernel solved the problem for me.
A few weeks ago -- when I started running stable/11 for more than merely smoke-testing, and I thus needed to be able to suspend & resume -- I appended the line:
to /boot/loader.conf, and that got suspend/resume working for me (both for stable/11 and head; stable/10 didn't need it). This was while running x11/nvidia-driver-346.96.
I have (of course) left that specification in while I attempted to use x11/nvidia-driver-367.35.
So while it's good to note that switching from vt to sc while running nvidia-driver-367.35 works for some, it does not work for all... even in configurations where nvidia-driver-346.96 worked (and -340.96 works).
Maintainer feedback? (Resp. is this still relevant?),
I think https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237050 should resolve this, if anyone wants to double check.