On the test system I was able to reproduce the problem and it was due to the selected cipher having insufficient cryptographic strength to pass HTTP/2 TLS profile validation. The selected cipher was one I added as a stopgap for FPR7 to fix another site which was still working (and did not use HTTP/2, hence it didn't exhibit the issue). Disabling that cipher restored the new failing site, but caused the site I put the workaround for in FPR7 to fail, so in no situation could I get both sites to be happy with the set available. Although I didn't really want to do this, the only real solution here was to upgrade NSS, the underlying cryptographic library, to add additional more modern ciphers to replace the older one that now needed to be reverted. With this in place and some other fixes, now both sites work, and this probably fixes others.
The reason I was reticent to update NSS (and the underlying NSPR library) was because of some custom changes and because I was worried changes in cipher coverage would break compatibility. However, there wasn't a lot of choice here, so I manually patched up our custom AltiVec-accelerated NSPR to a current release and spliced in a newer NSS overlaid with our build system changes. I tested this on a few sites I knew to be using old crypto libraries and they still seemed to connect fine, and as a nice side benefit some of the more modern ciphers are more efficient and therefore improve throughput a bit. It also makes the likelihood of successfully updating TenFourFox to support TLS 1.3 much higher; if this sticks, I may attempt this as soon as FPR20.
There are a couple sundry minor changes to be implemented at final release, mostly minor bug fixes, but I want to get this beta in testing as quickly as possible within the shrinking rapid release timeframe. I have otherwise intentionally limited the scope of FPR19 to mostly just the crypto upgrade so that we have a clear regression range. If you notice sites have stopped being accessible in FPR19, please verify they are working in FPR18 (people say "I remember it worked," but sites change more than TenFourFox does, so please check and save us some time here), and if it does indeed work in FPR18 report it in the comments so I can analyse the problem. I am very unlikely to revert this change given that it's necessary going forward and probably the best of the available options, but if I can add exceptions that don't compromise overall security I'm willing to do so in the name of supporting backwards compatibility with sites the browser used to be able to access. FPR19 goes final parallel with Firefox 73 and 68.5 somewhere around February 11.