+## 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.
+
+The hardware is responsible for atomically switching out ISANS into the
+relevant xLAST-ISANS (and back again on exit). See Privileged Traps,
+above.
+
+## If the ISANS is just bits of an instruction that are to be prefixed by the cpu, can those bits contain immediates? Register numbers?
+
+The concept of a CSR containing an immediate makes no sense. The concept
+of a CSR containing a register number, the contents of which would, presumably,
+be inserted into the NS, would immediately make that register a permanent
+and irrevocably reserved register that could not be utilised for any other
+purpose.
+
+This is what the CSRs are supposed to be for!
+
+It would be better just to have a second CSR - ISANS2 - potentially even ISANS3
+in 60+ years time, rather than try to use a GPR for the purposes for which CSRs
+are intended.
+
+## How does the system indicate a namespace is not recognised? Does it trap or can/must a recoverable mechanism be provided?
+
+It doesn't "indicate" that a namespace is not recognised. WLRL fields only
+hold supported values. If the hardware cannot hold the value, a trap
+**MUST** be thrown (in the UNIX platform), and at that point it becomes the
+responsibility of software to deal with it.
+
+## What are the security implications? Can some ISA namespaces be set by user space?
+
+Of course they can. It becomes the responsibility of the Supervisor Mode
+(the kernel) to treat ISANS in a fashion orthogonal to the PC. If the OS
+is not capable of properly context-switching securely by setting the right
+PC, it's not going to be capable of properly looking after changes to ISANS.
+
+## Does the validity of an ISA namespace depend on privilege level? If so how?
+
+The question does not exactly make sense, and may need a re-reading of the
+section on how Privilege Modes, above. In RISC-V, privilege modes do not
+actually change very much state of the system: the absolute minimum changes
+are made (swapped out) - xEPC, xSTATUS and so on - and the privilege mode
+is expected to handle the context switching (or other actions) itself.
+
+ISANS - through LAST-ISANS - is absolutely no different. The trap and the
+kernel (Supervisor or Hypervisor) are provided the *mechanism* by which
+ISA Namespace *may* be set: it is up to the software to use that mechanism
+correctly, just as the software is expected to use the mechanisms provided
+to correctly implement context-switching by saving and restoring register
+files, the PC, and other state. The NS effectively becomes just another
+part of that state.
+
+