I like to look at how usable the abstraction is from the perspective of the consuming client first, and only second from the perspective of its internal implementation.
If you already have a sizeable code base, what I would do is to look at the code that is consuming this (set of) abstraction(s).
Do calling consumers pass constants or variables for that parameter?
At one extreme, if users of these methods always pass constants, then those are really two different methods that should simply have two different names, and the parameter should be removed from both.
At the other extreme, if users never pass constants, always a variable, then it makes sense to keep a single signature with a differentiating parameter.
Of course, we can do both, if there are significant uses of constants being passed as well as uses of the variable, where one implementation (e.g. taking the variable or separate methods) can be written in terms of the other(s), and vice versa, without necessarily affecting the consuming clients.