I'd also like to point out that unsafe, as I've proposed, is generally consistent with Rust as prior art. Rust allows unsafe {}, but also unsafe fn, unsafe trait, and unsafe impl:

By default, unsafe fn also acts like an unsafe {} block around the code inside the function. This means it is not just a signal to the caller, but also promises that the preconditions for the operations inside the function are upheld. Mixing these two meanings can be confusing, so the unsafe_op_in_unsafe_fn lint can be enabled to warn against that and require explicit unsafe blocks even inside unsafe fn.

In Rust, disallowing unsafe fn in favor of a nested unsafe block is specified as a lint rule.

There is one thing about function coloring an unsafe function has over async/await that makes it somewhat more palatable, which is that you can introduce an unsafe {} block in safe code to perform the operation. That almost makes me want to have both unsafe function ("it is unsafe to call me and my contents are unsafe") and function () unsafe { } ("my contents are unsafe, but it is safe to call me as I have done my due diligence to ensure I am safe at the boundaries"), mostly because I really am not a fan of the namespace nesting style often seen in C++, i.e.

function f() { unsafe { 
  ...
} }

In other words, this

unsafe function readMessage(lck, workArea) { ... }
unsafe function writeMessage(workArea, message) { ... }
unsafe function processMessage(message) { ... }

function processWorkArea(mut, workArea) unsafe {
  using lck = new UniqueLock(mut);
  let message;
  while (message = readMessage(lck, workArea)) {
    const result = processMessage(message);
    writeMessage(workArea, result);
  }
}

Doesn't seem quite so bad to me (though I still prefer function() unsafe { } to function() { unsafe { } })

I'd really like to be able to write conventional JS with shared structs when I know I already have exclusive access to an object. If we only have unsafe {}, I can't write this

unsafe function doWork(task, timeout = task.timeout ?? 1000) { ... }

and instead must write this

function doWork(task, timeout) {
  unsafe {
    timeout ??= task.timeout ?? 1000;
    ...
  }
}

Or use module blocks, e.g.:

unsafe module M {
  export shared struct AtomicValue { ... }
}
export * from M;

I'd also be fine with postfix-unsafe markers for declarations (function f() unsafe { }) and potentially allowing unsafe in both positions (unsafe function f() {} and function f() unsafe {}, though unsafe function f() unsafe {} is redundant). I'd also be fine with unsafe markers for parameters much like I suggested for variable and field initializers in a world where we either can't have postifx-unsafe or if postfix-unsafe can't include parameters, e.g.:

function doWork(task, unsafe timeout = task.timeout ?? 1000) {
  unsafe { ... }
}

IMO, only having unsafe {} is not ideal, though do unsafe {} would make that somewhat more bearable, e.g.:

function doWork(task, timeout = do unsafe { task.timeout } ?? 1000) {
  unsafe { }
}

But for that we would need do {} to advance.

In an earlier example I showed how you might decompose a series of unsafe operations into multiple functions, where only the entrypoint function would perform any coordination, i.e.:

unsafe function readMessage(...) { ... }
unsafe function writeMessage(...) { ... }
unsafe function processMessage(...) { ... }
function processWorkArea(workArea) {
  unsafe {
    // performs locking
    // calls readMessage/writeMessage/processMessage
  }
}

If we have unsafe function, we can enforce that safe code cannot invoke an unsafe function directly, or inadvertently.
If we do not have unsafe function and only have unsafe {}, then we cannot perform such enforcement and there is no clear delineation between a safe entrypoint and unsafe code:

function readMessage(...) { unsafe { ... } }
function writeMessage(...) { unsafe { ... } }
function processMessage(...) { unsafe { ... } }
function processWorkArea(workArea) {
  unsafe {
    // performs locking
    // calls readMessage/writeMessage/processMessage
  }
}

Here, readMessage will not perform any independent coordination or locking as it expects to be called by processWorkArea, which is the function that would actually perform locking. A user could inadvertently invoke readMessage from "safe" code, resulting in a data race. The only way to enforce this is by convention, thus you would instead want to write this as:

function readMessageUnsafe(...) { unsafe { ... } }
function writeMessageUnsafe(...) { unsafe { ... } }
function processMessageUnsafe(...) { unsafe { ... } }
function processWorkArea(workArea) {
  unsafe {
    // performs locking
    // calls readMessageUnsafe/writeMessageUnsafe/processMessageUnsafe
  }
}

It's not quite so easy if I want to make doWork available to code outside of the block:

let doWork;
unsafe {
  doWork = function() { ... };
}

This would be a regular frustration developers would encounter, both here and with import/export, or shared struct bodies, etc.

Note that we could also simply allow

unsafe {
  let doWork = ...; 
}

I point to the parallel of namespace blocks in C++, where indenting them like:

unsafe {

let doWork = ...

}

makes it less confusing.