This is accurate. The SynchronizationContext.Current property uses the current thread's m_ExecutionContext field. Which is a private field of the Thread class, that's why you don't see it in the IntelliSense dropdown.
It is important it works that way, the default SynchronizationContext doesn't synchronize anything. Its Post() method target runs on a threadpool thread. Marshaling the target call to a specific thread is a very nontrivial thing to do. That requires help from the target thread, it needs to provide a solution to the producer-consumer problem. The generic solution is a loop that retrieves messages from a thread-safe queue. Exactly the way that the UI thread of a Winforms or a WPF app works, they "pump the message loop". Application.Run() starts that loop.
So only the UI thread of such an app can support a synchronization provider that doesn't use threadpool threads to run the Post() delegate target. Accordingly, Winforms and WPF install their own synchronization provider as soon as you create a Form or Window. And only code that runs on the UI thread will see that non-default provider from the SynchronizationContext.Current property.
The consequence is that you must initialize code that need to marshal calls back to the UI thread on the UI thread. So for example creating a BackgroundWorker must be done on the UI thread. Or a task created with TaskScheduler.FromCurrentSynchronizationContext. There can technically be more than one thread that displays UI, whatever thread the init code runs on determines where the Post() delegate target will run. Which probably explains your problem, if your init code runs on a worker thread then the Post() target runs on a threadpool thread. You can pass a reference to the Synchronization.Current object to a worker thread, as long as you obtained that reference on the UI thread.