Right know I just added a generic for table, that calls the integer64 method as soon as integer64 is present in an argument of the table call. This way table(int64, chr) is consistent to table(chr, int64) - at least in my understanding.
In a second step one could change the logic in table.integer64 to not coerce and not use caching or the like.

Originally posted by @hcirellu in #209 (comment)

As originally designed, table.integer64() was only meant to take in integer64 columns, thus coercing all ... inputs to integer64 makes some sense.

But under S3 dispatch, doing so can cause some information loss for some types (certain values of double, as well as complex and character).

My current understanding is table.integer64() is implemented as it is for speed, and mixing types would require revisiting the underlying sorting mechanism.

Still, I think accuracy is more important -- if non-coercible types are found, we should escape from attempting the 64-bit-sort-based approach.