ConfigureAwait(false) is not the end-all fix-everything for SynchronizationContext, unfortunately. It affects that specific await only, saying that if it does need to complete asynchronously to not use the SynchronizationContext. To be completely effective, however, you must include it on EVERY await down the call stack. It doesn’t guarantee that the SynchronizationContext is dropped for the continuation because the continuation may be synchronous instead.
In order to try to reduce this problem, the Couchbase SDK does try to use .ConfigureAwait(false) throughout. However, it is very easy to miss. Some code change that missed ConfigureAwait(false) is, in fact, the likely culprit for the change in behavior after 3.1.3.
My point is that relying on that behavior isn’t safe. It could get fixed in the next release, and another spot could appear in the next release after that. Also, race conditions can occur that might make a missed spot not apparent until your application is under load.
If you really must use .GetAwaiter().GetResult() and rewriting to true async isn’t an option, then I strongly recommend using a pattern like AsyncHelper.RunSync which takes some performance penalties in exchange for the guarantee that it won’t deadlock.