The limit on the resulting number of rows (was max(nrow(x),nrow(i)) and now nrow(x)+nrow(i)) was just to catch huge allocations from (likely) misspecified joins, always due to dups in i's join columns.
Now that i is checked for duplicates directly in a very efficient way (thanks to Arun), we can just simplify the argument and do away with the limit altogether. This'll be cleaner since currently if there are dups in i, it may or may not need allow.cartesian depending on the sizes. However, the vast majority of problems were when there are no dups in i - that's now fully fixed and doesn't need any change.
Related #851, #742 and #800.