new display server, but [...]

The most major change for a user is that Wayland is designed for every frame to be perfect, so no frame is present in intermediate state. This goal is achieved by Wayland server and clients (applications) negotiating Wayland surface (window) state, and Wayland compositor rendering the last consistent state. Wayland compositor doesn't render beyond the output (display) refresh rate (e.g. 30 Hz, 60 Hz, 120 Hz, 144 Hz, or variable refresh rate) unlike X11 where rendering is not synchronized with the display's refresh rate, resulting in visual tearing artifacts on X11, whereas Wayland presents the last frame per display refresh, resulting in visually perfect frames. Additionally, clients that render continuously (show animations) can use frame callbacks to render on demand by compositor, in order to save system resources when client is minimized, off-screen, or in any other state when continuous rendering isn't optimal. Performance can also be improved compared to X11, as nowadays modern applications don't use underlying X11 drawing primitives, so X11 is often odd and becomes overhead in the graphics pipeline. Wayland also provides easier use of modern zero-copy APIs such as dmabuf which are used in e.g. high performance video processing for high resolutions such as 4K and beyond.

Wayland also features better isolation by design. Communication between clients and compositor is based on Wayland protocol, which consists of interfaces which define the list of messages: requests, which are sent by client to the server, and events, which are sent by the server to client. Wayland compositor, which is granted permission to access evdev by seat daemon described below, dispatches events from seats, or groups of input devices (keyboard, mouse, or other events that can be handled via libinput), to appropriate Wayland clients. Additionally, clients cannot access other clients' surfaces or know their global position. This model provides improved security over X11 where state is global and accessible to any application with X11 socket access.

Wayland is state of the art display server maintained by various contributors, and its ecosystem is actively expanding. Graphical toolkits such as GTK3+, Qt 5 (with qt5-wayland package), SDL2, standalone Wayland clients such as multimedia/mpv, Web browsers such as www/firefox with WebRTC screen sharing via multimedia/pipewire with XDG portal, and WebKitGTK+ and GTK3+ based browsers have Wayland support, and this list is not exhausting, as many items on the https://arewewaylandyet.com/ and beyond are in the FreeBSD ports collection living in various categories, including Wayland's own category, wayland/. There is also a seamless compatibility layer for X11 software called XWayland, but the need for it will diminish over the time as more software gains Wayland support or becomes Wayland-only.

Wayland compositors have various backends to render frames on, including the DRM backend where Wayland compositor is launched via DRM enabled vt(4) console, or X11 and Wayland backends for Wayland-on-X11 or Wayland-on-Wayland nesting respectively.

DRM mode is supported on AMD and Intel GPUs via graphics/drm-kmod. NVIDIA graphics driver doesn't provide DRM enabled vt(4) console, thus only nesting is possible on NVIDIA GPUs, and the usability on NVIDIA is questionable.

AFAIK it was regressed sometime and wasn't fixed. No idea if it is the case now, I don't want to build KDE to test and I don't trust non-reproducible packages from pkg.FreeBSD.org.

DRM and evdev, or use "The seatd daemon helps manage [...]" instead below, or use the description in my comments above.

XDG_RUNTIME_DIR is concatenated with WAYLAND_DISPLAY to form the path to unix(4) socket used for Wayland transport method, and can be used as a path for shared memory for use with e.g. mmap(), so placing it on ZFS would be suboptimal, maybe suggest that tmpfs is the only acceptable option.

traditional -> legacy

Maybe mention dbus and seatd-launch, e.g. dbus enable and "seatd-launch dbus-run-session sway" ?

Does swaylock require consolekit session nowadays when under DRM backend?

I don't think XWayland binds and listens a network socket, check yourself via e.g. sockstat -l -v6 (or v4).

Did I mention net/waypipe in the previous review?

I would prefer something like [::] (or "::" if wayvnc accepts only that for some reason) instead, as IPv4 is legacy and new deployments shouldn't use it. Besides, a warning that either 0.0.0.0 or [::] listen on every configured IP address on any interface and makes wayvnc accessible to the whole Internet would be nice.

TLS is hard to get right and might be wrong to describe, and I think ipsec(4) suits better, but fine, this is nitpicking.