LTspice - Simulation of a variable inductance
The behavioural inductor accepts expressions that are time-dependent. There is a keyword, x, signifying the current through the inductor, which is nothing but a shortcut for I(L1) (assuming some L1). For behavioural capacitors, x is the voltage across them, and in both cases the behavioural expressions are solved is by applying a partial derivative w.r.t. each variable (from LTspice &gt; Circuit Elements &gt; C. Capacitor):

LTspice will compile this expression and symbolically differentiate it with respect to all the variables, finding the partial derivative's that correspond to capacitances.

This means that, in order for a behavioural expression to reflect the desired change, it needs to be integrated, first.
So, for example, if the inductance needs to vary according to the mathematical expression
$$f(x)=-2x^3+3x^2+1$$
(with x being time), then the behavioural expression needs to be integrated first, resulting in
$$g(x)=-\dfrac12x^4+x^3+x$$
To test this, apply a unity current ramp (which results in the derivative of the current as 1) and read the voltage across the inductor (overlapping voltages have been shifted by a small amount):

La has the raw equation as its behavioural expression, and V(a) shows a parabola identical to what B2 shows, V(c2), which means the interpreted result is
$$h(x)=-6x^2+6x=\dfrac{\text{d}}{\text{d}x}f(x)$$
Lb has \$g(x)\$ as its behvioural expression, which means the voltage across it, V(b), is the same as the one supplied by B1, V(c). And, since the example implied the usage of time as the variable x, Lb2 shows that the voltage across it, V(b2), reflects the integrated expression with time as the variable. If another quantity would have been needed instead of x, such as a voltage, or a current, or any other time-dependent expression, it would have to be integrated, first.
Caution is needed when dealing with expressions, since they are, usually, within a bounded interval. Exceeding the limits may have very unpleasant consequences, and I don't mean the kind that are visible (voltages going sky-high, or similar), but the kind that are insiduous and give apparent good results, yet wrong -- the best debugging sessions. In this case, x (and, thus, time) is assumed to vary between [0...1], which means that simulating with .tran 2 will show software fireworks, but for time≤1.5 the results will seem correct.
Be careful when handling the mathematical expressions in LTspice: -x**4 will not give you what you expect (see the paragraph below the boolean table in the help: LTspice &gt; Circuit Elements &gt; B.). You will need to write them in the two ways shown: with appropriate parenthesis, or with a multiplier in front of it (dummy or not).

I would have replied to your comment, but this information should be added here, better. While x does signify the current through the inductor, using I(La) as the current through La is not a good idea, because of the following quote from the help (LTspice &gt; Circuit Elements &gt; B., the 3rd point):

[...] it is assumed that the circuit element current is varying quasi-statically, that is, there is no instantaneous feedback between the current through the referenced device and the behavioral source output.

I(La) meets the above condition, so the proper, 40+ year old way to use the current through a device is to add a series, zero valued voltage source as a sensor, then use that current, in the same way a CCCS (F source) or CCVS (H source) would be used.
Now, LTspice considers inductors as voltage sources, so it is possible to avoid the use of a series voltage source as a current sensor (e.g. a CCCS would have the value La 1), but not in this case, because of the quote above. Therefore, using I(La) may (most probably will) result in an error -- best use x.
OTOH, if, for example, the inductance needs to vary according to some external voltage, then there is no need to use x, but the expression still needs to be integrated. If the voltage varies according to a known mathematical function, the behavioural expression for Flux= can be derived and written, explicitely, otherwise something along these lines should be used, where G1 and C1 act as a unity integrator:

The same slight offset has been applied, like in the picture above, for the same reason. Note that, due to the internal derivative, there may be initial spikes of MV or similar, lasting some 1 ns, hence the 1 ms skipped time in .tran 0 1 1m. Otherwise the response is right.