|EXT001| 0 | 1 | nnnn | load/store suffix=defined-word      |
 |EXT001| 1 | 1 | nnnn | reg-to-reg suffix=defined-word       |
 
+and so when bit 6=0 there is space to create an entirely
+new suite of encodings including new 32-bit instructions.
 
 this "doubling" is already public and part of EXT001, the idea
 here is to mirror that (bit 6), but unlike EXT001, use bit 7
 | PO  | 0 | 1 | nnnn | new, vector (SVP64)       |
 | PO  | 1 | 1 | nnnn | old, vector (SVP64)       |
 
+there are some special-cases here, involving bits 8-31 but
+they are degenerate.  let us set `Scalar Identity Behaviour`:
+
+| 0-5 | 6 | 7 | 8-31 | Description               |
+|-----|---|---|------|---------------------------|
+| PO  | 0 | 0 | 0000 | new, scalar (SVP64Single) |
+| PO  | 1 | 0 | 0000 | old, scalar (SVP64Single) |
+| PO  | 0 | 1 | 0000 | new, vector (SVP64)       |
+| PO  | 1 | 1 | 0000 | old, vector (SVP64)       |
+
+there is *one* set of encodings here which are redundant:
+
+* bit 6=1
+* bit 7=10
+* bits 8-31=0000
+
+this is a duplication of the **existing** v3.0B 32-bit
+Scalar operations.  is it worth special-casing for
+"Reserved" honestly i do not know if it's worth it.
+it would be:
+
+| 0-5 | 6 | 7 | 8-31 | Description               |
+|-----|---|---|------|---------------------------|
+| PO  | 0 | 0 | nnnn | new, scalar (SVP64Single) |
+| PO  | 1 | 0 | 0000 | `RESERVED` |
+| PO  | 1 | 0 | !zero | old, scalar (SVP64Single) |
+| PO  | 0 | 1 | nnnn | new, vector (SVP64)       |
+| PO  | 1 | 1 | nnnn | old, vector (SVP64)       |