I understand your point of view which is really in adequation with DbC, which is fine.
But I really dislike the check .. then .. end 

I see your comment   -- invariant
but you should be more precise and name the various invariant and precondition involved.

in fact, I think I would prefer a 

if attached unavailablity_message as m then 
   ....
else
    check 
          unavailable: False -- implied by precondition `unavailable' and invariant `unavailability_message_attached'
    end
end

Which is not the same , since they will be no check violation raised if assertion are disabled.

But to workaround this delicate decision about DbC and defensive programming, we could allow Void unavailable_message when unavailable is True ... and use a predefined default message when `unavailable' is True and the `unavailable_message' is Void

That might sound like a hack and change a little bit the orginal semantic.

Anyway, 3 ways
1) the code from your patch
2) the if attached .. then  else check False end 
3) allow detachable message

I let you choose between 1,2 and 3