O motivo
WATCH não é exposto diretamente é por causa de como o SE.Redis foi projetado para multiplexar comandos de diferentes pilhas de chamadas em uma única conexão. Isso torna necessário que qualquer trabalho de transação seja muito rigidamente administrado. Não tenho certeza de qual seria o propósito de "inalterado" por si só , sem comparação com algum valor conhecido - caso contrário, você está apenas criando uma condição de corrida. Definitivamente seria possível adicionar suporte para isso, mas eu realmente gostaria de entender o caso de uso esperado primeiro. Você pode explicar?
Re sua edição; seu exemplo preferido (o último) simplesmente não é possível com redis - nada a ver com SE.Redis; se você fizer um
GET dentro de um MULTI , você não obtém a resposta até que o EXEC conclui - então você não pode usar o valor no SET :ainda não está disponível . Se não fosse pela multiplexação, você poderia reordenar um pouco seu segundo exemplo (com base no que o SE.Redis faz):
WATCH key
val = GET key
MULTI
val = val + 1
SET key $val
EXEC
este é o típico uso de
WATCH :você assiste as coisas que você está consultando com antecedência, então você sabe que {key} permanece inalterado durante este loop (ou pelo menos, a transação será abortada; nenhum estado inconsistente). No entanto, WATCH não funciona bem com um multiplexador , e é por isso que o SE.Redis força você a buscar o valor antes da transação , permitindo que você compare o valor para afirmar que ele não foi alterado. Mesmo resultado; abordagem ligeiramente diferente, mas é seguro para multiplexadores. Para saber mais sobre esse assunto veja aqui. 
