Absolutely. I support this idea. I don't imagine it will be an enormous amount of work, since all commands already support operating on a selection of tracks.

I'm wondering how this would work. Would the system dispatch a single command which now has a new concept of the count being passed to it, or would it dispatch the regular command count times?

I imagine it'd have to be the former, because gt gt is not the same as 2gt.

Each command would have to define what the count means to it, I think.

From an architecture point of view, what about this?

Command stays as it is. Things which directly implement Command don't support counts, and you get an error if you try to call them with a count.

A new class CountableCommand (or something) descends from Command an accepts a count, and it is passed to the handler method as an extra argument. The command decides what to do with this.

For convenience, a new class RepeatableCommand (or something) descends from CountableCommand and handles the count by simply running its handler count times.

(I don't know Go -- totally likely a different architecture is better!)

The Command class should definitely be aware of the count, and execute as needed. Otherwise, e.g. 1000x would send thousand commands to the MPD server, instead of issuing a single command.

Is there anything to be gained from separating "one-off" commands from countable commands on a class level? In my opinion, it gains nothing except adding complexity. If the command explicitly does not support counting, it could just return an error.

I'm not really certain it would be boilerplate code. As every command would have to handle the count, they might as well implement their functions to be countable from the start. As for the commands that doesn't support count or it doesn't make sense (such as play, pause, stop, single, repeat, etc.) they could also possibly silently ignore the counter?

This is related to #92.