For an Evolution operator where the generator has data, like op = qml.evolve(0.5 * qml.X(0), 1.2), the terminal leaves

>>> qml.pytrees.flatten(op)[0]
[0.5, 1.2]
>>> op.data
(1.2,)

While on its own, this violation of expectations seems relatively harmless, it causes errors when used with bind_new_parameters.

User examples include:

@qml.qnode(qml.device('default.qubit'), diff_method="parameter-shift")
def c(x):
    qml.evolve(0.5 * qml.X(0), x)
    return qml.expval(qml.Z(0))
qml.grad(c)(qml.numpy.array(0.5))

File [/pennylane/ops/functions/bind_new_parameters.py:221](/pennylane/ops/functions/bind_new_parameters.py#line=220), in bind_new_parameters_sprod(op, params)
    218 @bind_new_parameters.register
    219 def bind_new_parameters_sprod(op: SProd, params: Sequence[TensorLike]):
    220     # Separate dispatch for `SProd` since its constructor has a different interface
--> 221     new_scalar = params[0]
    222     params = params[1:]
    223     new_base = bind_new_parameters(op.base, params)

IndexError: tuple index out of range

The above failure could be fixed by simply adding a registration to bind_new_parameters for the special Evolution behavior.

But we end up in a situation where not all numerical data can be updated and changed by bind_new_parameters. For example, bind_new_parameters is often used to convert all numerical data to numpy so it can be used with devices that can't handle interface data. If the coefficient is not considered by bind_new_parameters, we might send interface data to a device that can't handle it.

The coefficient of the generator could also be trainable. If we simply ignore the coefficient of the generator, we might not properly calculate any derivatives for it.