mention polyfill limitations

1 files changed, 6 insertions, 2 deletions

diff --git a/HighLevelGoals.md b/HighLevelGoals.md
index c560891..eb9bbff 100644
--- a/HighLevelGoals.md
+++ b/HighLevelGoals.md
@@ -11,8 +11,12 @@
    evolution story of the web; engines should not need multiple, versioned
    decoders.
 5. Design and implement incrementally:
-    * [v.1](V1.md) of the standard will be a Minimum Viable Product with a full, effective [polyfill][] via client-side compilation to [asm.js][] and thus run on existing browsers;
-    * subsequent versions will add more [features](EssentialPostV1Features.md) prioritized by feedback.
+    * [v.1](V1.md) of the standard will be a Minimum Viable Product with a [polyfill][] via client-side compilation to [asm.js][] and thus run on existing browsers.
+      In semantic corner cases (such as out-of-bounds and alignment, which evoke Undefined Behavior in C and C++), where asm.js does not have ideal semantics,
+      the default polyfill would diverge for performance reasons (it would also be possible to run a more precise but slower polyfill, but almost all
+      real-world applications are not expected to need to do so).
+    * subsequent versions will add more [features](EssentialPostV1Features.md) prioritized by feedback. Some of those features might not be polyfillable
+      to asm.js in a practical way.
 6. Design to execute within and integrate well with the existing web platform:
     * execute in the same semantic universe as JavaScript;
     * allow synchronous calls to and from JavaScript;