Ah, that surprises me, but OK, noted.
Nevertheless, if JDK 17 becomes the baseline default target of both code generation and incidental tools, that won’t stop Scala things using 17 bytecode from being run when, say AWS lambda gets upgraded to force use of JDK 21.
(Incidentally, would one run a Scala build in Lambda? I bet someone, somewhere has tried doing a build like that …)
It’s the reverse problem that makes me recommend JDK 17 - conservative organisations that cutover once in a blue moon to whom JDK 21 isn’t on the cards yet. I’m sure that most if not all of the readership are doing their private builds on JDK 26 but it’s where applications are deployed and where CI builds are done that are the important thing.
If everyone did all their development, building and deployment in containers that allow the latest things to be provisioned, then we could just go with the bleeding edge straightaway, but my experience is otherwise. All this cloud stuff is still a revelation at some places I can think of.
(I’m out of the loop a bit these days, so happy to be corrected if the last dinosaur has gone extinct. 
)
A incidental question to the floor - what exactly does targeting JDK 21 / 25 provide for Scala that 17 doesn’t give? You can always run on 25 anyway….