For an abstract interface, it's less-flexible if there are defaults for any parameters because it can locks subclasses in to a particular convention or expected type.  However here, it's probably not good to have ``args`` at all because it implies **all** interface types support some kind of additional behaviour modifiers.  Consider this, what happens if the underlying interface is not 'cli' but some network-based "thing", ``args`` would have a totally different meaning.  In that case, you'd have to write a cli-options parser for the network-based interface to keep the parameter values transparent (i.e. a big hassle).

Better to just leave it simple as ``remove_by_id(self, container_id)`` and allow the subclasses to "do the right thing".  It's totally fine if subclasses define additional methods to do specialized-stuff.  However I don't think it's wise lock all descendants into data/behaviour that is non-generic.  Does that make sense?

I think you could implement an ``args`` extension similar to how you've added other interface subclasses. For example, hang a ``remove_by_id_force`` off of one of them.  Have that method append to an instance-attribute ``args`` that's popped off in an overridden ``docker_cmd()``.