Would it make sense for Enumerable to implement to_ary as well?
Matz is not agreeing as you see in #1893:
" Implicit conversion methods such as #to_ary and #to_str should be
defined only when the object provides (almost) equivalent behavior
(i.e. method set). Enumerable and Array are not the case. "
Or is this purely a bug in Array#&?
Array#& (as well as #|, #-, #uniq and #uniq!) compare elements using #hash and #eql? as they build an Hash for performance reasons (O(m+n) instead of O(m*n), m=size of self, n=size of other array (or self in case of #uniq{,!})).
This is still not documented however for some of these methods, I'll try to fix this.
I think the reason this is done is semantically it makes less sense to have an intersection of an Array and an Enumerable. You would not have the reverse, as Enumerable does not have set-like methods (Array is already stealing a bit of Set in this regard because it is very practical).
As an illustration, [1,2,3] + enumerable raises an error as intended (unless enumerable implements #to_ary). Too loose conversion is dangerous (for example IO#each will only yield once the lines).
It could be done though at the expense of using #each instead of directly iterating on the Array structure, or converting with #to_a. I am not sure the gain of having the implicit #to_a would be clear, so I propose to use [1,3,5] & Thing.new.to_a in your case.
About #1028, it was just a bug in the way of checking whether an argument is an Array or not, the code handling Enumerable was already there (that code is actually almost duplicated with enum_take()).