How would this work?

The middleware doesn't have any dependencies other than rack and the ruby standard library.

It's std now but not for long

I think, if you're moving this here anyways, does it make sense to require the user to pass in an object that adheres to the rack logger interface themselves?

The current plan is for us to wait and see if anyone complains about the deprecation. If no one complains, we'll probably remove it with no replacement. As you've said, the current implementation leaves a lot to be desired.

I'm not sure I understand the rationale for moving this to rack-contrib. My understanding of SPEC is that rack.logger must be set to some logger-like object. This means that either:

1. Rack (or servers that implement rack) will provide a default (doesn't-depend-on-logger) implementation that conforms to SPEC; or
2. Every single application in existence will have to either provide their own rack.logger implementation or else include Rack::Logger as their first middleware, making rack-contrib de facto a dependency of basically every app.

Since I understand that (1) is the plan, I kinda feel like this middleware would get essentially zero usage.

rack.logger is optional, per my understanding. From Rack::Lint: https://github.com/rack/rack/blob/38b178e9ce3b30453cd5340a92093128bfb4fa36/lib/rack/lint.rb#L232

This is preceded by the following:

   ## Additional environment specifications have approved to
   ## standardized middleware APIs. None of these are required to
   ## be implemented by the server.

Ah, thanks for pointing that out. I'd somehow skipped over that when refreshing my cache of SPEC. That explains why moving this middleware over here makes sense.

For now, let's just close this PR.