Hey Patrick,
The use case for `implicit_order_column` is only intended for configuring the behaviour of finder methods where an ordering is implied, i.e. `first` and `last`, and where the default of using the primary key to order results in unpredictable behaviour, i.e. when the PK is a UUID. It wasn't the intention that this be used as a way to define a default order on finder methods in general.
With regard to the batch finders specifically, enabling the order column to be overridden would open them up to subtle bugs and undesirable behaviour, particularly if the order column is one that isn’t guaranteed to be unique, e.g. the `created_at` timestamp. This could result in records being skipped or processed more than once.