They mean RTSS’ “scanline sync”, which basically allows making micro-adjustments to the FPS limiter in real-time to move the screen tear line up and down the display. This ability allows RTSS’ frame rate limiter to pace the limiter against VBLANK, to essentially hide the screen tearing even in V-Sync Off scenarios.
Edit: Blur Busters have a great post on it here: RTSS Scanline Sync HOWTO - Blur Busters Forums
Oh. I know what Scanline Sync is. I read Civ’s post to mean “Custom Sync” was a feature I was using in D3D12. It’s definitely not, and neither is Scanline Sync 
I toyed around with the idea of Scanline Sync for a while, but came to the conclusion that waitable swapchains are better, because they can add/remove frames from the render queue if the GPU starts to struggle. There’s more ability to mitigate stutter when you can dynamically adjust the length of that queue.
SK’s limiter is first and foremost designed to fix 1% / 0.1% low events. Scanline Sync exists basically for the purpose of latency only, so we’re operating at two different ends. That said, even though latency’s never been a big focus, I also have a design that works well in that department too
I never really understood the focus of input latency myself beyond what V-Sync adds. Eliminate the additional input latency caused by V-Sync, and that takes care of my main concern. Beyond that I personally focus entirely on overall frame pacing and not necessarily trying to gain additional milliseconds here or there in regards to input latency (often at the detriment of frame pacing).