This seems to be in common for most schemes, as the Butcher tableau for the implicit part has only nonzero elements in the first column. However, this does not seem like an implicit treatment. What have I missed?
This is called an ESDIRK method, or an Explicit first step Singly-Diagonal Implicit Runge-Kutta method. The explicit first step is required to achieve the high order conditions for DAEs (called "stiffly-accurate"). Another order condition is that FSAL is required, so you'll notice that all of the schemes do that too, and since it's ESDIRK you can just flip that over to be the first stage and so actually there's no explicit evaluation required (depending on the quantities you are saving).
You need to be careful there though since the iterations will only be numerically stable for highly stiff equations if you relax the
dt*f term instead of the input itself. This is something discussed in Shampine's TRBDF2 paper. Thus the Sundials implementation is a good resource, but if you've ever opened up Sundials you'll notice that something weird happens in the test equations (and the test equations require dropping the convergence coefficient quite a bit). My theory is that this is due to their iteration choice since the DifferentialEquations.jl versions don't have this issue. This means that, when you do find an equation where they work, they have higher runtimes than they should... For reference, here's the open source Julia implementation of the 3rd order KenCap in out-of-place form if you want to copy some things. In-place forms along with the other orders are also in that file.
As mentioned in another post, the FSAL property is only on the implicit part of the tableau. Thus when you use this as an ESDIRK method it is FSAL, and that's one of the stiffly-accurate order conditions. However, the update value is not directly from the implicit tableau when solving with IMEX, so the first step of the implicit part does need a function evaluation.