I couldn't get your approach to work either.  But I was able to use a property-table observer to make it work:

local Require = require 'Require'.path ("../common")
local Debug = require 'Debug'
require 'strict'

local LrBinding = import 'LrBinding' 
local LrDialogs = import 'LrDialogs' 
local LrFunctionContext = import 'LrFunctionContext' 
local LrRecursionGuard = import 'LrRecursionGuard'
local LrView = import 'LrView' 

local bind = LrView.bind 
local f = LrView.osFactory()
local recursionGuard = LrRecursionGuard ("check")

local function userReallyWantsToDoThis (prop, key, newValue)
    recursionGuard:performWithGuard (function ()
        if "ok" == LrDialogs.confirm ("Do you want to do this?") then
            prop.check = newValue
        else
            prop.check = not prop.check
            end
        end)
    end

LrFunctionContext.callWithContext ("", function (context) 
    local prop = LrBinding.makePropertyTable (context) 
    prop.check = false
    prop:addObserver ("check", userReallyWantsToDoThis)
    LrDialogs.presentModalDialog {title = "Test",  
        contents = f:column {bind_to_object = prop, 
            f:checkbox {title = "Some Title",
                checked_value = true, unchecked_value = false,
                value = bind {key = "check"}}}}
    end)

[[Apologies if anyone has seen this response previously. Responded by email and it appears that never made it through to the forums.]]

Hi Don,

I was trying to work out the logic behind this. Let me know whether you agree with the reasoning here.

The value is being bound to propertyTable.someProperty. Every time this property's value changes it then executes all observers including the transform function to convert the value into the value needed by the checkbox.

In your original transform function it was synchronously resetting that exact same bound value to a different value. There are only two ways I think that situation can be handled:

1) when you set the property value from within the transform function, recursively call all observers (and thus the transform function) again before setting the value

2) suspend all observers for the property value during the transform function to avoid getting into a recursive loop

Looks like the team have gone with option 2) here.

So to me this behaviour makes sense as otherwise it would be difficult to impossible to commit the property table processing with a consistent state.

If above holds true it is possible that you don't even need the sleep() call in your async task. Setting the property value from within the async task might be enough to allow the original property table observer to commit the value in a consistent state. If the sleep() proves necessary then people who make extensive use of async tasks will need to be very careful when setting property table entries, lest they encounter intermittent issues where observers don't fire because of this very situation.

Did that make sense?

Matt