New principle: A Promise represents completion or a value, not a callback (#342)

index.bs

@@ -1877,6 +1877,40 @@ If the bytes in the buffer have a natural intepretation
 as one of the other TypedArray types, provide that instead.
 For example, if the bytes represent Float32 values, use a {{Float32Array}}.
 
+<h3 id="allow-microtask-switches">A Promise represents a value, not a callback</h3>
+
+Avoid requiring that something needs to happen synchronously within
+a promise resolution or rejection callback.
+
+Authors tend to expect that any `async` function can be wrapped
+in another that appends synchronous code at the end e.g. to inspect state
+using try/catch. But the `await` queues a microtask:
+<div class="example">
+```js
+async function fooWrapper() {
+  const foo = await platform.foo();
+  console.log("success");
+  return foo;
+}
+
+(async () => {
+  const foo = await fooWrapper();
+  foo.bar(); // on the same task, but not the same microtask that logged "success"
+})();
+```
+</div>
+
+To support this pattern, a specification that wishes to restrict `bar()` to
+only succeed if called immediately following a promise resolving can
+minimally limit it to the same task, but not the same microtask.
+
+<div class="note">
+One case where this came up was the [captureController.setFocusBehavior()](https://w3c.github.io/mediacapture-screen-share/#dom-capturecontroller-setfocusbehavior)
+method, where timing concerns were solved by adding a timeout on top of
+the requirement of it being called on the same task that resolves the
+`getDisplayMedia()` promise.
+</div>
+
 <h2 id="event-design">Event Design</h2>
 
 <h3 id="one-time-events">Use promises for one time events</h3>