Por que o primeiro argumento do colchete deve executar no máximo uma operação de bloqueio?

Em Programação Paralela e Concorrente em Haskell de Simon Marlow, a implementação de bracketé mostrada,

bracket
        :: IO a         -- ^ computation to run first (\"acquire resource\")
        -> (a -> IO b)  -- ^ computation to run last (\"release resource\")
        -> (a -> IO c)  -- ^ computation to run in-between
        -> IO c         -- returns the value from the in-between computation
bracket before after thing =
  mask $ \restore -> do
    a <- before
    r <- restore (thing a) `onException` after a
    _ <- after a
    return r

e um comentário segue. Aqui está a parte que está me intrigando

[…] É normal que beforecontenha uma operação de bloqueio; se uma exceção for gerada enquanto beforeestiver bloqueado, não haverá danos. Mas beforedeve executar apenas uma operação de bloqueio. Uma exceção gerada por uma segunda operação de bloqueio não resultaria em afterexecução. […]

Não entendi bem esse comentário, então gostaria de alguns esclarecimentos sobre ele.

Para esclarecer, não entendi nem a parte de que nenhum dano é causado : algumas páginas antes (p. 159), a seguinte tentativa falhada (segunda) de chamar takeMVar, executar uma operação dependendo de seu conteúdo e, finalmente, colocar o resultado dessa operação de volta na MVarvia putMVaré mostrada,

problem :: MVar a -> (a -> IO a) -> IO ()
problem m f = mask $ \restore -> do
  a <- takeMVar m
  r <- restore (f a) `catch`  \e -> do putMVar m a; throw e
  putMVar m r

Ao analisar este exemplo, "aceito" como um fato que takeMVarnão pode ser alterado maté que retorne; na verdade, isso foi retirado do texto:

seria seguro que exceções fossem levantadas até o ponto em que takeMVarretornasse.

e sinto que entendo o que se segue (eu acho ).

Mas voltando à implementação de bracket, e se beforeinternamente usar takeMVar, e uma exceção assíncrona ocorrer após o takeMVarretorno dela (esvaziando um MVar)? Isso não é um problema, justamente pelo motivo de estarmos usando mask+ restore, ou seja, tal exceção seria adiada até que o argumento para restore, que é thing a, comece a ser executado, momento em que o manipulador de exceções necessário está em vigor, neste caso via `onException` after a?

E o que dá errado se beforefizer outra chamada para a operação de bloqueio, digamos takeMVarnovamente para simplificar? O problema ocorre porque a exceção poderia ocorrer enquanto takeMVar o bloqueio estiver em andamento, portanto, na janela de tempo em que as exceções não são mascaradas, de modo que a exceção sairia de bracket, deixando o MVarargumento that was para o primeiro takeMVarnão vazio, mas em um estado diferente do original, dado que afternão teve a chance de ser executado?

É isso?

Além disso, a página do documento não menciona isso, ou não vejo como isso está implícito.