I've never used incomplete args, but for a triangle wave my workaround was just use an infinitesimal PW rather than zero. SPICE2 used to be pretty unforgiving.
In my experience timestep errors come from circuit badness - too little C, too much gain, hysteretic features that you can't step back and forth into one solution. It's not "the behaviouralness" but that you can do bad / unrealistic things with it, If you can narrow down the failing nodes and inspect what's there, poke around right at the point of fail, you may find threads to pull on. It's easy to make a behavioral model that works well within "recommended limits" but blows up hard, not far outside....
This looks like a big deal especially for digital-first or not-mostly-analog design. Now can veriloga be invoked too while "run under coctb" like if you had a working SPICE:verlioga lashup working in a ngspice-first design project? Anybody plow that road yet?
My own preference is to fine grain the data sets (like outer loop "iterations" get their own file, because often "corner" is not loopable per se; assign and follow an index of some sort). I have decades-old PTSD from watching days-long "monolithic" MC runs fail 4/5 of the way through and the data, lost. Better to save often and move on, in uncertain or high pressure times. If you create yourself a little "widget" which exports as a real V, I, element value that is a printable output, and make it...
Easiest way would be to make an alt model with same params except add a gauss() multiplier / adder to the Ise / c2 param that delivers the Vbe mismatch you want. Then just invoke those models instead, just where you want to observe. You could go more elaborate like put a property on the schematic that passes on through, but then more to manage; a one-off might want the easiest way. In the old days (the ancestor od cdsSpice) MC analysis was all donw with racks and racks of statistical functions, params...
Convergence fails and solution "weirdness" can be fellow travelers. Analog circuits can have more than one stable, valid solution - DC polystable, and "traps" that a circuit might be provoked into (high current latched state, in the circuitry not the parasitics) or fail to crawl out of (stuck zero-bias when should start up). The simulator is probably not lying. No, you're lying probably. Like too much ideality makes current go boom (where'd you find that ideality, in stock?) or lack of proper junction...
Convergence fails and solution "weirdness" can be fellow travelers. Analog circuits can have more than one stable, valid solution - DC polystable, and "traps" that a circuit might be provoked into (high current lathed state, in the circuitry not the parasitics) or fail to crawl out of (stuck zero-bias when should start uo). The simulator is probably not lying. No, you're lying probably. Like too much ideality makes current go boom (where'd you find that ideality, in stock?) or lack of proper junction...
I don't use KiCAD but the error message seems to be trying to say that some symbol has not got its model property set (every "generic" device primitive has to either have that as a "steering" property, or have that relation "baked in" if it's meant to be a standard part type, no substitutions. Select the schematic instance of one of the offenders, property-edit it, look for anything to do with model name (you may then also need to tell it -where-, in some searchPath setting, to look). May have to...