Tagging future features with icon. (#839)

Added brief item on multiple return.

1 files changed, 27 insertions, 12 deletions

diff --git a/BinaryEncoding.md b/BinaryEncoding.md
index 935e747..6d3d9bf 100644
--- a/BinaryEncoding.md
+++ b/BinaryEncoding.md
@@ -6,17 +6,19 @@ The binary encoding is a dense representation of module information that enables
 small files, fast decoding, and reduced memory usage.
 See the [rationale document](Rationale.md#why-a-binary-encoding) for more detail.
 
+[:unicorn:][future general] = Planned [future](PostMVP.md) feature
+
 The encoding is split into three layers:
 
 * **Layer 0** is a simple binary encoding of the bytecode instructions and related data structures.
   The encoding is dense and trivial to interact with, making it suitable for
   scenarios like JIT, instrumentation tools, and debugging.
-* **Layer 1** provides structural compression on top of layer 0, exploiting
+* **Layer 1** [:unicorn:][future compression] provides structural compression on top of layer 0, exploiting
   specific knowledge about the nature of the syntax tree and its nodes.
   The structural compression introduces more efficient encoding of values, 
   rearranges values within the module, and prunes structurally identical
   tree nodes.
-* **Layer 2** Layer 2 applies generic compression algorithms, like [gzip](http://www.gzip.org/) and [Brotli](https://datatracker.ietf.org/doc/draft-alakuijala-brotli/), that are already available in browsers and other tooling.
+* **Layer 2** [:unicorn:][future compression] Layer 2 applies generic compression algorithms, like [gzip](http://www.gzip.org/) and [Brotli](https://datatracker.ietf.org/doc/draft-alakuijala-brotli/), that are already available in browsers and other tooling.
 
 Most importantly, the layering approach allows development and standardization to
 occur incrementally. For example, Layer 1 and Layer 2 encoding techniques can be
@@ -25,7 +27,7 @@ compression techniques  stabilize, they can be standardized and moved into nativ
 implementations.
 
 See
-[proposed layer 1 compression](https://github.com/WebAssembly/decompressor-prototype/blob/master/CompressionLayer1.md)
+[proposed layer 1 compression :unicorn:][future compression]
 for a proposal for layer 1 structural compression.
 
 
@@ -67,7 +69,7 @@ All types are distinguished by a negative `varint7` values that is the first byt
 
 Some of these will be followed by additional fields, see below.
 
-Note: Gaps are reserved for future extensions. The use of a signed scheme is so that types can coexist in a single space with (positive) indices into the type section, which may be relevant for future extensions of the type system.
+Note: Gaps are reserved for [future :unicorn:][future general] extensions. The use of a signed scheme is so that types can coexist in a single space with (positive) indices into the type section, which may be relevant for future extensions of the type system.
 
 ### `value_type`
 A `varint7` indicating a [value type](Semantics.md#types). One of:
@@ -92,7 +94,7 @@ In the MVP, only one type is available:
 
 * [`anyfunc`](AstSemantics.md#table)
 
-Note: In the future, other element types may be allowed.
+Note: In the [future :unicorn:][future general], other element types may be allowed.
 
 ### `func_type`
 The description of a function signature. Its type constructor is followed by an additional description:
@@ -105,7 +107,7 @@ The description of a function signature. Its type constructor is followed by an
 | return_count | `varuint1` | the number of results from the function |
 | return_type | `value_type?` | the result type of the function (if return_count is 1) |
 
-Note: In the future, `return_count` and `return_type` might be generalised to allow multiple values.
+Note: In the [future :unicorn:][future multiple return], `return_count` and `return_type` might be generalised to allow multiple values.
 
 ## Other Types
 
@@ -150,7 +152,7 @@ A packed tuple that describes the limits of a
 | initial | `varuint32` | initial length (in units of table elements or wasm pages) |
 | maximum | `varuint32`? | only present if specified by `flags` |
 
-Note: In the future, the "flags" field may be extended, e.g., to include a flag for sharing between threads.
+Note: In the [future :unicorn:][future threads], the "flags" field may be extended, e.g., to include a flag for sharing between threads.
 
 ### `init_expr`
 The encoding of an [initializer expression](Modules.md#initializer-expression)
@@ -221,7 +223,8 @@ The type section declares all function signatures that will be used in the modul
 | count | `varuint32` | count of type entries to follow |
 | entries | `func_type*` | repeated type entries as described below |
 
-Note: In the future, this section may contain other forms of type entries as well, which can be distinguished by the `form` field of the type encoding.
+Note: In the [future :unicorn:][future types],
+this section may contain other forms of type entries as well, which can be distinguished by the `form` field of the type encoding.
 
 ### Import section
 
@@ -503,7 +506,8 @@ The `br_table` operator implements an indirect branch. It accepts an optional va
 branches to the block or loop at the given offset within the `target_table`. If the input value is 
 out of range, `br_table` branches to the default target.
 
-Note: Gaps in the opcode space, here and elsewhere, are reserved for future extensions.
+Note: Gaps in the opcode space, here and elsewhere, are reserved for
+[future :unicorn:][future general] extensions.
 
 ## Call operators ([described here](Semantics.md#calls))
 
@@ -512,7 +516,9 @@ Note: Gaps in the opcode space, here and elsewhere, are reserved for future exte
 | `call` | `0x10` | function_index : `varuint32` | call a function by its [index](Modules.md#function-index-space) |
 | `call_indirect` | `0x11` | type_index : `varuint32`, reserved : `varuint1` | call a function indirect with an expected signature |
 
-The `call_indirect` operator takes a list of function arguments and as the last operand the index into the table. Its `reserved` immediate is for future use and must be `0` in the MVP.
+The `call_indirect` operator takes a list of function arguments and as the last
+operand the index into the table. Its `reserved` immediate is for
+[future :unicorn:][future multiple tables] use and must be `0` in the MVP.
 
 ## Parametric operators ([described here](Semantics.md#type-parametric-operators))
 
@@ -571,10 +577,12 @@ The `memory_immediate` type is encoded as follows:
 As implied by the `log2(alignment)` encoding, the alignment must be a power of 2.
 As an additional validation criteria, the alignment must be less or equal to 
 natural alignment. The bits after the
-`log(memory-access-size)` least-significant bits must be set to 0. These bits are reserved for future use
+`log(memory-access-size)` least-significant bits must be set to 0. These bits
+are reserved for [future :unicorn:][future threads] use
 (e.g., for shared memory ordering requirements).
 
-The `reserved` immediate to the `current_memory` and `grow_memory` operators is for future use and must be 0 in the MVP.
+The `reserved` immediate to the `current_memory` and `grow_memory` operators is
+for [future :unicorn:][future multiple tables] use and must be 0 in the MVP.
 
 ## Constants ([described here](Semantics.md#constants))
 
@@ -727,3 +735,10 @@ The `reserved` immediate to the `current_memory` and `grow_memory` operators is
 | `i64.reinterpret/f64` | `0xbd` | | |
 | `f32.reinterpret/i32` | `0xbe` | | |
 | `f64.reinterpret/i64` | `0xbf` | | |
+
+[future general]: PostMVP.md
+[future multiple return]: PostMVP.md#multiple-return
+[future threads]: PostMVP.md#threads
+[future types]: FutureFeatures.md#more-table-operators-and-types
+[future multiple tables]: FutureFeatures.md#multiple-tables-and-memories
+[future compression]: https://github.com/WebAssembly/decompressor-prototype/blob/master/CompressionLayer1.md