Davis Vaughan

Here is a dev tidyr example where the strictness currently comes into play. I think this current behavior has nice theoretical properties, but it might be too strict. I _think_...

This also showed up in a revdep https://github.com/ffverse/ffscrapr/pull/344 The problem essentially boiled down to the fact that we can't currently combine `list + list_of` even if the `list` has compatible...

> and then vec_cast() might fail when vec_ptype2() succeeds. oooh I don't like that if we can avoid it

Looking at this again, I think I'd be fine with this kind of lax list: ```r list_of + list_of = list_of # same inner type list_of + list_of = list_of...

Highly related to changing tidyr `nest()` to return list-ofs. The current coercion rules are a little too strict for us to be able to do this, but it would be...

The proxy method isn't recursive, so we currently consider the result of `vec_proxy()` to be a "base" like type where `length()` would work on it (with the exception of data...

Do you (in theory) have more than one `field`? Where would you store the 2nd field in a vctrs-vctr type? I have also brought up the record type data.table issue...

With more complex classes like pseries, which have an attribute that must be sliced alongside the core data, package authors generally have to do a little more work to get...

Oh I sort of added this already with the unmerged `vec_duplicate_flg()` (which was a bad alias for `vec_duplicate_detect()`) https://github.com/r-lib/vctrs/pull/764/files#diff-786a8b6fcb86825de6ab1d7cd2b2c6abR492

Eventually yes!