A note here, as I've seen a few conditions getting written this way lately: there's seldom a need to have a return value from a condition that tells the raise-site that it should fail; the handler itself can just fail (and indeed, untrapped conditions already fail). There's just as much context (more actually) visible to a backtrace if you let the handler / absence-of-handler itself fail.

Generally the only things that should show up in the return slot of a condition are data to use for recovery-and-continuation: sentinel values or replacement values, things that represent the handler saying "oh, well, use this value instead". If no such data is required or plausible (i.e. if the only reasonable thing one might do to recover is "ignore the error") then just put `()` in the return slot. If control proceeds past the `condition.raise()` line, you know a caller trapped the error and wants you to ignore it and continue.