One problem here is that if k is a function of time, then the named variable ddx will depend on the time derivative of k, D(k), and there is no way for MTK to know what the derivative of this time-dependent parameter is. The problem goes away if you don't name ddx, and instead write the model as

julia> @component function FilteredInput(; name, x0=0, T=0.1)
           params = @parameters begin
             k(t) = x0
             T = T
           end
           vars = @variables begin
             x(t) = k
             dx(t) = 0
           end
           systems = []
           eqs = [
             D(x) ~ dx
             D(dx) ~ (k - x)/T
           ]
           return ODESystem(eqs, t, vars, params; systems, name)
       end

julia> @mtkbuild sys = FilteredInput()

julia> ModelingToolkit.observed(sys)
Equation[]

since then MTK has no reason to make ddx available as an observed, and the detivative of k never appears in any expression, it's only being integrated.

Furthermore, if you intend for k(t) to be piecewise constant, the derivative of k is infinite or ill defined at the time points when k changes.

Making parameter derivatives zero should handle this?

We do need to make sure that when a parameter is a function, say a datainterpolation, that we still handle that case correctly.

Making parameter derivatives zero should handle this?

"handle"... if the derivative is zero then there's no need to have the parameter depend on time. If the parameter truly does vary with time it's wrong to just assume that the derivative is zero.

Well the issue here is that discrete variables and parameter functions need to do this separately.

In both cases is it wrong to assume that the derivative is zero. A discrete-time variable that is piecewise constant has an ill-defined derivative (in the non-distribution sense at least) at the time point when it changes value, if the model is such that it depends on this derivative, the model is probably wrong. If the parameter is a function of time and MTK knows the derivative of this function it is fine, otherwise erroring is the only reasonable option.

See also #2823 (from #2823 (comment) and below). A good solution to this issue would probably also solve that issue.