Not as I understand it. When I've seen this discussed, a "logout requirement" has usually meant some stakeholder thinks they need a way to prevent previously issued access tokens from being used even though the tokens are signed by the trusted authorization server and not expired (i.e. still valid). This requirement asks that you find a way to instantly shut off access even though the auth server has previously issued access tokens that should entitle the bearer to perform actions against protected resources until the token expires.

Blocking refresh in the authorization server is trivial, but trying to implement the same on access tokens in the resource server at the point of use breaks the entire security model of JWT. It's unreliable, because now every resource server has to take on partial responsibility for authorization which multiplies opportunities for mistakes. As the OP points out, you need to keep track of some sort of block list and lose out on many of the benefits of JWT (i.e. a resource server being able to rely fully on claims in a signed token before allowing an action).

When people show up with this kind of requirement, in my experience, it is often because they foolishly configured a client with a very long expiration on access tokens (e.g. ~months/years instead of ~minutes/hours). This creates a problem when some aspect of a user's access needs to change (e.g. disgruntled employee was fired, customer didn't pay their bill, etc). You can address this more easily by pairing a short access token lifetime with a long refresh token lifetime.

Ah, right. Yeah, I've had people ask for that too. It defeats the whole point of the JWT though. You might as well use sessions at that point because that's essentially what they are if you want to be able to instantly revoke (e.g. check every request).