The problem with BPT may not be new in Poser 11.3
Indeed this is an old issue, and - surprise! - it has nothing to do with Poser or Superfly. Branched Path Tracing seems to have been sabotaged by nVidia for years, apparently as means to keep Blender3D Cycles from competing with I-ray. They do this by undermining the GeForce driver. I know it sounds like I am speculating here, but the evidence is rather compromising for nVidia. In a nutshell, while using the same GeForce drivers, BPT works in I-ray, but not with competing rendering engines that rely on nVidia drivers. With nVidia I-ray it just works as it should, but with Cycles and Superfly, it just tends to crash your computer.
As a result, you will see a warning in the Poser render settings whenever you enable BPT in GPU mode. Look for the little blue "i" icon at the upper right corner when you are in GPU and enable BPT. If you hover your mouse over it, it will advise you to disable BPT in GPU mode because it can cause "instabilities". In my experience, it can go as far as to crash Windows 10 into a BSOD, where there was a case where it has even corrupted Windows and I couldn't boot up anymore.
That was years ago, and now the issue is not as severe. At best it will crash the render, but not Poser or Windows, which is good. It's funny that nVidia "could not fix" the issue with their drivers that undermine ONLY the competition, no matter how many years have passed by now. nVidia considers this as an "unresolved bug" on their own GeForce drivers, which happens to benefit them, and undermine the competition. A little too convenient if you ask me.
As for BPT, it scales up render multi-threading in the GPU, which should speed up your render considerably. As a result, you can use MUCH less pixel samples when BPT is enabled. Otherwise we have to bump up pixel samples to MUCH higher values, which increases render times exponentially. For example, I can produce a noise-free 900x1200 render with as little as 7 pixel samples with BPT enabled, and it finishes in a couple of minutes. With BPT off, the same render will now require as much as 40~50 pixel samples to produce the same result, and renders times take as along as 10~15 minutes.
The thing about pixel samples is that it is a render thread multiplier. Number of pixel samples vs number of primary rays:
1ps = 1pr
2ps= 4pr
3ps= 9pr
4ps= 16pr
...
7ps= 49pr
As you can see, increasing pixel samples by a single digit produces a quadratic exponential increase on the number of ray castings. When BPT is enabled, these rays will be computed in parallel, while otherwise they will be calculated in series, one at a time, which kills render performance when using the GPU.
Pixel samples are tied to the bucket size, so one thing affects the other - they work together. In a nutshell, if the bucket size is smaller than the largest image dimension (width or height), this will increase the number of required threads, which increases render time. However, bucket size is limited by how much VRAM you have available in your video card - you cannot just bump it at will. You have to try to make it as large as possible, before you run out of memory. This will produce the fastest possible render, but that requires using BPT in GPU mode.
Having that said, we can see how nVidia has something to gain my limiting us from using BPT In GPU mode because they make the GPU hardware, and also the driver that enables each feature. It's freely available in I-ray, but limited and even dangerous in competing rendering engines, like Cycles and Superfly. Even if nVidia is not sabotaging the competition on purpose, it's darn too convenient that they "can't fix" this "bug" after these many years. It's too convenient that this driver "bug" only affects the competition. They could fix everything else, just not this.