I'm trying to update a mid-sized server application from 4.0.33 to 6.0.0, and I had Claude perform the update and audit. I've found what appear to be a handful of regressions (mostly during 5.x) and have created or commented on tickets, but there are a few intended behavior changes I had questions about.
1. Spring Data's `Sort` type (representing a sequenced set of sort fields and their order) implements `Iterable<Order>` but not `Collection`. In 4.x, I defined some fixed constants for expected sort specs and then used a `switch`: `case OLDEST_FIRST -> /* do search */`. GROOVY-7919 applies isCase to any type implementing `Iterable`, not just `Collection`, meaning that the `switch` now reads that as "is the Sort value OLDEST_FIRST contained in the Orders listed in this Sort?", which is of course false. Is there a clean/efficient way to express "I want the switch to use equality here", such as wrapping `case /*Predicate.*/isEqual(OLDEST_FIRST)`? 2. The 5.x changes in Map-vs-property handling introduced a nasty gotcha where constants defined in a closure's containing class are now _categorically inaccessible_ by simple name inside the closure; a Map answers every property access, with null if nothing else. While this may be consistent, it's surprising, and it's devilish to track down, especially because _whether it happens depends on the annotations on the extension method_. Would it be feasible to have an STC warning when using a symbol inside a closure that matches an otherwise visible variable or constant but is shadowed because the delegate defines `get`? 3. I'm very happy to have real interface default methods, but I appear to be losing parameter default values. Is there a particular reason why interface methods can't have default values, implemented as delegating default methods on the generated interface? Thanks to the team and especially Eric for all the improvements!
