As a super quick test to this theory about cgsb being the right variable to use for CGS as opposed to Xyce's CAPcgsb, I tried just substituting that and doing a totally trivial comparison between Xyce and ngspice on the netlist "test1.cir" from the Xyce_Regression suite, modified to print cgs for both ngspice and Xyce. I found that with no modification the codes were grossly different across the dc sweep. Simply changing the code to store cgsb instead of CAPcgsb didn't fix it, though, because cgsb was always zero across the DC sweep.
I then looked at how SPICE and Xyce set the "ChargeComputationNeeded" boolean and found that Xyce disables it for DC sweeps, but SPICE enables it if the circuit mode is "MODEDCTRANCURVE".
Tweaking Xyce's BSIM4v7 code to add "dcsweepFlag" to the list of states that enable ChargeComputationNeeded *AND* changing the output variable storage to cgsb instead brought Xyce's CGS in agreement with ngspice's.
So I think the code for Xyce is being overly restrictive of when ChargeComputationNeeded is set and *also* is incorrectly saving the wrong variable for CGS.
I do not know how badly other things will break if ChargeComputationNeeded is set this way, though. Something for the team to look into with all that extra time they have (not).