One thing I'm not aware of is whether the size of the list that's forced contributes to how much work is done to compute it. That is, it's already pretty slow at 5 items. Does changing it to 30 or whatever increase the work significantly (ie. is the list produced lazily)? If the same work is done regardless, then it doesn't really matter.

The list ultimately comes from

Clearly some work is saved by truncating that list but the only meaningful source of laziness I see here is if names env contains some lazy values.

What would be a good way to confirm whether this adds a lot of work or not?

One way we could test this is do a prerelease and see what people find in their usage of it. It's not hard to change this back to 5 (or some other higher-than-5 number). This is also not a breaking change, so we can adjust this as needed.

I think trialing this for 0.15.3 would be fine.

Part of me wonder if this should be merged as the first 0.15.4 prerelease. If we had merged this back when I got Ryan's approval, then we could have gotten early feedback about whether 30 is a good number or causes problems. With 0.15.3 coming out next Tuesday (per our 6-week release cycle), this PR hasn't had a lot of soak time.

Alternatively, this could get merged and 0.15.3 released. And if there are any issues, we make a quick 0.15.4 release that reverts this change. I think I'd lean towards this approach.

With 0.15.3 released, I'm merging this. We have another 6 weeks to see what issues this change may create before making a full release.