+## Why WARL will not work and why WLRL is required
+
+WARL requires a follow-up read of the CSR to ascertain what heuristic
+the hardware *might* have applied, and if that procedure is followed in
+this proposal, performance even on hardware would be severely compromised.
+
+In addition when switching to foreign architectures, the switch has to
+be done atomically and guaranteed to occur.
+
+In the case of JIT emulation, the WARL "detection" code will be in an
+assembly language that is alien to hardware.
+
+Support for both assembly languages immediately after the CSR write
+is clearly impossible, this leaves no other option but to have the CSR
+be WLRL (on all platforms) and for traps to be mandatory (on the UNIX
+Platform).
+
+## Is it strictly necessary for foreign archs to switch back? <a name="foreignswitch"></a>
+
+No, because LAST-ISANS handles the setting and unsetting of the ISANS CSR
+in a completely transparent fashion as far as the foreign arch is concerned.
+Supervisor or Hypervisor traps take care of the context switch in a way
+that the user mode (or guest) need not be aware of, in any way.
+
+Thus, in e.g. Hypervisor Mode, the foreign guest arch has no knowledge
+or need to know that the hypervisor is flipping back to RV at the time of
+a trap.
+
+Note however that this is **not** the same as the foreign arch executing
+*foreign* traps! Foreign architecture trap and interrupt handling mechanisms
+are **out of scope** of this document and MUST be handled by the foreign
+architecture implementation in a completely transparent fashion that in
+no way interacts or interferes with this proposal.
+
+## Can we have dynamic declaration and runtime declaration of capabilities? <a name="dynamic"></a>
+
+Answer: don't know (yet). Quoted from Rogier:
+
+> "A SOC may have several devices that one may want to directly control
+> with custom instructions. If independent vendors use the same opcodes you
+> either have to change the encodings for every different chip (not very
+> nice for software) or you can give the device an ID which is defined in
+> some device tree or something like that and use that."
+
+dynamic detection wasn't originally planned: static
+compilation was envisaged to solve the need, with a table of
+mvendorid-marchid-isamux/isans being maintained inside gcc / binutils /
+llvm (or separate library?) that, like the linux kernel ARCH table,
+requires a world-wide atomic "git commit" to add globally-unique
+registered entries that map functionality to actual namespaces.
+
+where that goes wrong is if there is ever a pair (or more) of vendors
+that use the exact same custom feature that maps to different opcodes,
+a statically-compiled binary has no hope of executing natively on both
+systems.
+
+at that point: yes, something akin to device-tree would be needed.
+
+# Open Questions <a name="open-questions"></a>
+
+This section from a post by Rogier Bruisse
+<http://hands.com/~lkcl/gmail_re_isadev_isamux.html>
+
+## is the ISANS CSR a 32 or XLEN bit value? <a name="isans-32-or-xlen"></a>
+
+This is partly answered in another FAQ above: if 32 bits is not enough
+for a full suite of official, custom-with-atomic-registration and custom-without
+then a second CSR group (ISANS2) may be added at a future date (10-20 years
+hence).
+
+32 bits would not inconvenience RV32, and implementors wishing to
+make significant altnernative modifications to opcodes in the RV32 ISA space
+could do so without the burden of having to support a split 32/LO 32/HI
+CSR across two locations.
+
+## is the ISANS a flat number space or should some bits be reserved for use as flags?
+
+See 16-bit RV namespace "page" concept, above. Some bits have to be unary
+(multiple simultaneous features such as LE/BE in one bit, and augmented
+Floating-point rounding / clipping in another), whilst others definitely
+need to be binary (the most obvious one being "paging" in the space currently
+occupied by RVC).
+
+## should the ISANS space be partitioned between reserved, custom with registration guaranteed non clashing, custom, very likely non clashing?
+
+Yes. Format TBD.
+
+## should only compiler visible/generated constant setting with CSRRWI and/or using a clearly recognisable LI/LUI be accommodated or should dynamic setting be accommodated as well?
+
+This is almost certainly a software design issue, not so much a hardware
+issue.
+
+## How should the ISANS be (re)stored in a trap and in context switch?
+
+See section above on privilege mode: LAST-ISANS has been introduced that
+mirrors (x)CAUSE and (x)EPC pretty much exactly. Context switches change
+uepc just before exit from the trap, in order to change the user-mode PC
+to switch to a new process, and ulast-isans can - must - be treated in
+exactly the same way. When the context switch sets ulast-isans (and uepc),
+the hardware flips both ulast-isans into uisans and uepc into pc (atomically):
+both the new NS and the new PC activate immediately, on return to usermode.
+
+Quite simple.
+
+## Should the mechanism accommodate "foreign ISA's" and if so how does one restore the ISA.
+
+See section above on LAST-ISANS. With the introduction of LAST-ISANS, the
+change is entirely transparent, and handled by the Supervisor (or Hypervisor)
+trap, in a fashion that the foreign ISA need not even know of the existence
+of ISANS. At all.
+
+## Where is the default ISA stored and what is responsible for what it is after
+
+Options:
+* start up
+* starting a program
+* calling into a dynamically linked library
+* taking a trap
+* changing privilege levels
+
+These first four are entirely at the discretion of (and the
+responsibility of) the software. There is precedent for most of these
+having been implemented, historically, at some point, in relation to
+LE/BE mode CSRs in other hardware (MIPSEL vs MIPS distros for example).
+
+Traps are responsible for saving LAST-ISANS on the stack, exactly as they
+are also responsible for saving other context-sensitive information such
+as the registers and xEPC.