"It is very annoying when you need to add a dependency and suddenly you have to touch 50+ injection points because that thing is widely used"
You don't have to update the injection points, because the injection points don't know the concrete details of what's being injected. That's literally the whole point of dependency injection.
Edited to add: Say you have a class A, and this is a dependency of classes B, C, etc. Using dependency injection, classes B and C are passed instances of A, they don't construct it themselves. So if you add a dependency to A, you have to change the place that constructs A, of course, but you don't have to change B and C, because they have nothing to do with the construction of A.
"because it does preloading directly in javascript, it can't possibly follow the HTTP semantic of not actually applying cookies until later when the cached route is used"
I may be wrong, but I don't think using JavaScript vs using the standard HTML <link> element to prefetch makes a difference here. I don't see anything in the HTML specs about preload or prefetch delaying cookie setting to sometime after the resource is actually loaded (although admittedly I find this bit of the spec somewhat hard to read, as it's dense with references to other parts of the spec). I tried it out, and, both Firefox and Chrome set the cookies for preloaded and prefetched links when the resource is loaded, even if the resource is never actually used.
I initially interpreted "unaccounted-for null values may cause compile-time warnings, but not compile-time errors" as meaning "in some cases, an unaccounted-for null value might not cause a compile-time error", but in the context of the rest of the spec, I think it actually means "unaccounted-for null values are not permitted to cause compile-time errors, only warnings", which seems like a bad idea to me. I can see why allowing implicit conversion from unannotated "Object" to "Object!" is a reasonable compromise to work with existing code, but I don't see why conversion from "Object?" to "Object!" would not cause a compile-time error.
Worse, permitting this conversion at compile time means developers will ignore the warning, so we'll have actual codebases which include these conversions. Any later change to enforce nullability checking at compile time will then have a significant backwards compatibility cost.
That's right, I think it's really "soft deletion as a blanket rule" which is the anti-pattern; soft-deletion is one option which (IMO) is used too often without thinking about specifically what you need to achieve. If soft-deletion is used as a blanket rule, you're more likely to want to try and abstract it away via an ORM or similar, which tends to be fragile (I agree views aren't fragile, but they do add another layer of complexity in defining the relationship between the application logic and the schema). If soft deletion is chosen judiciously and represented explicitly in the business logic, it's less likely to cause problems (the "archived state" in the post is kind of an explicitly represented soft delete).
I don't think there's an explicit reference in the JavaScript spec to numbers being treated this way, because this is how all variables are treated in JavaScript - the relevant part of the specification is probably the definition of the "PutValue" abstract operation[1], which doesn't include any special cases for numbers (or other primitive types) vs. objects.
You don't have to update the injection points, because the injection points don't know the concrete details of what's being injected. That's literally the whole point of dependency injection.
Edited to add: Say you have a class A, and this is a dependency of classes B, C, etc. Using dependency injection, classes B and C are passed instances of A, they don't construct it themselves. So if you add a dependency to A, you have to change the place that constructs A, of course, but you don't have to change B and C, because they have nothing to do with the construction of A.