I hadn't considered the case for specifying a read-behind. I could see how it'd be useful when say the retention period on the topic itself may be a couple of days but you'd want to read behind maybe just an hour or so to prime the cache and then get anything new that comes in after that. I could also see going back a specific number of messages being convenient when either the timespan of the data is long (e.g.: for low volume data) or the user might just want to prime the cache based on the last x messages. Allowing for the combo of those settings is another route to go down where the read behind will start at the offset which was found at the point where either of the criteria was first met.
If you create a JIRA ticket for the auto.offset.reset task, I can work on that feature initially and create a pull request. For the time and/or count based read behind feature you described, I'd need to find some more concrete use cases that require a specific look behind config before going down that route but, I definitely agree that it'd be a better long term solution to allow for that level of flexibility.