+==RB not sure if this is still correct and relevant==
+
+The proposal is functionally similar to that of the mvendor/march-id
+except the non standard extension is explicit and restricted to a small set of well defined individual opcodes.
+Hence several extensions can be mixed and there is no state to be tracked over context switches.
+As such it could hypothetically be proposed as an independent Standard Extension.
+
+Despite the proposal (which is still undergoing clarification)
+being worthwhile in its own right, and standing on its own merits and
+thus definitely worthwhile pursuing, it is non-trivial and more
+invasive than the mvendor/march-id WARL concept.
+
+==RB==
+
+# Comments, Discussion and analysis
+
+TBD: placeholder as of 26apr2018
+
+## new (old) m-a-i tuple idea
+
+> actually that's a good point: where the user decides that they want
+> to boot one and only one tuple (for the entire OS), forcing a HARDWARE
+> level default m-a-i tuple at them actually prevents and prohibits them
+> from doing that, Jacob.
+>
+> so we have apps on one RV-Base ISA and apps on an INCOMPATIBLE (future)
+> variant of RV-Base ISA. with the approach that i was advocating (S-mode
+> does NOT switch automatically), there are totally separate mtvec /
+> stvec / bstvec traps.
+>
+> would it be reasonable to assume the following:
+>
+> (a) RV-Base ISA, particularly code-execution in the critical S-mode
+> trap-handling, is *EXTREMELY* unlikely to ever be changed, even thinking
+> 30 years into the future ?
+>
+> (b) if the current M-mode (user app level) context is "RV Base ISA 1"
+> then i would hazard a guess that S-mode is prettty much going to drop
+> down into *exactly* the same mode / context, the majority of the time
+>
+> thus the hypothesis is that not only is it the common code-path to *not*
+> switch the ISA in the S-mode trap but that the instructions used are
+> extremely unlikely to be changed between "RV Base Revisions".
+>
+> foreign isa hardware-level execution
+> ------------------------
+>
+> this is the one i've not really thought through so much, other than it
+> would clearly be disadvantageous for S-mode to be arbitrarily restricted
+> to running RV-Base code (of any variant). a case could be made that by the
+> time the m-a-i tuple is switched to the foreign isa it's "all bets off",
+> foreign arch is "on its own", including having to devise a means and
+> method to switch back (equivalent in its ISA of m-a-i switching).
+>
+> conclusion / idea
+> --------------------
+>
+> the multi-base "user wants to run one and only one tuple" is the key
+> case, here, that is a show-stopper to the idea of hard-wiring the default
+> S-mode m-a-i.
+>
+> now, if instead we were to say, "ok so there should be a default S-mode
+> m-a-i tuple" and it was permitted to SET (choose) that tuple, *that*
+> would solve that problem. it could even be set to the foreign isa.
+> which would be hilarious.
+
+jacob's idea: one hart, one configuration:
+
+>>> (a) RV-Base ISA, particularly code-execution in the critical S-mode
+>>> trap-handling, is *EXTREMELY* unlikely to ever be changed, even
+>>> thinking 30 years into the future ?
+>>
+>> Oddly enough, due to the minimalism of RISC-V, I believe that this is
+>> actually quite likely. :-)
+>>
+>>> thus the hypothesis is that not only is it the common code-path to
+>>> *not* switch the ISA in the S-mode trap but that the instructions used
+>>> are extremely unlikely to be changed between "RV Base Revisions".
+>>>
+>> Correct. I argue that S-mode should *not* be able to switch the selected
+>> ISA on multi-arch processors.
+>
+> that would produce an artificial limitation which would prevent
+> and prohibit implementors from making a single-core (single-hart)
+> multi-configuration processor.
+
+
+
+# Summary and Conclusion
+
+In the early sections (those in the category "no action") it was established
+in each case that the problem is not solved. Avoidance of responsibility,
+or conflation of "not our problem" with "no problem" does not make "problem"
+go away. Even "making it the Fabless Semiconductor's design problem" resulted
+in a chip being *more costly to engineer as hardware **and** more costly
+from a software-support perspective to maintain*... without actually
+fixing the problem.
+
+The first idea considered which could fix the problem was to just use
+the pre-existing MISA CSR, however this was determined not to have
+the right coverage (Standard Extensions only), and also crucially it
+destroyed state. Whilst unworkable it did lead to the first "workable"
+solution, "MISA-like".
+
+The "MISA-like" proposal, whilst meeting most of the requirements, led to
+a better idea: "mvendor/march-id WARL", which, in combination with an offshoot
+idea related to gcc and binutils, is the only proposal that fully meets the
+requirements.
+
+The "ioctl-like" idea *also* solves the problem, but, unlike the WARL idea
+does not meet the full requirements to be "non-invasive" and "backwards
+compatible" with pre-existing (pre-Standards-finalised) implementations.
+It does however stand on its own merit as a way to extend the extremely
+small Custom Extension opcode space, even if it itself implemented *as*
+a Custom Extension into which *other* Custom Extensions are subsequently
+shoe-horned. This approach has the advantage that it requires no "approval"
+from the RISC-V Foundation... but without the RISC-V Standard "approval"
+guaranteeing no binary-encoding conflicts, still does not actually solve the
+problem (if deployed as a Custom Extension for extending Custom Extensions).
+
+Overall the mvendor/march-id WARL idea meets the three requirements,
+and is the only idea that meets the three requirements:
+
+* **Any proposal must be a minimal change with minimal (or zero) impact**
+ (met through being purely a single backwards-compatible change to the
+ wording of the specification: mvendor/march-id changes from read-only
+ to WARL)
+* **Any proposal should place no restriction on existing or future
+ ISA encoding space**
+ (met because it is just a change to one pre-existing CSR, as opposed
+ to requiring additional CSRs or requiring extra opcodes or changes
+ to existing opcodes)
+* **Any proposal should take into account that there are existing implementors
+ of the (yet to be finalised but still "partly frozen") Standard who may
+ resist, for financial investment reasons, efforts to make any change
+ (at all) that could cost them immediate short-term profits.**
+ (met because existing implementations, with the exception of those
+ that have Custom Extensions, come under the "vendor/arch-id read only
+ is a formal declaration of an implementation having no Custom Extensions"
+ fall-back category)
+
+So to summarise:
+
+* The consequences of not tackling this are severe: the RISC-V Foundation
+ cannot take a back seat. If it does, clear historical precedent shows
+ 100% what the outcome will be (1).
+* Making the mvendorid and marchid CSRs WARL solves the problem in a
+ minimal to zero-disruptive backwards-compatible fashion that provides
+ indefinite transparent *forwards*-compatibility.
+* The retro-fitting cost onto existing implementations (even though the
+ specification has not been finalised) is zero to negligeable
+ (only changes to words in the specification required at this time:
+ no vendor need discard existing designs, either being designed,
+ taped out, or actually in production).
+* The benefits are clear (pain-free transition path for vendors to safely
+ upgrade over time; no fights over Custom opcode space; no hassle for
+ software toolchain; no hassle for GNU/Linux Distros)
+* The implementation details are clear (and problem-free except for
+ vendors who insist on deploying dozens of conflicting Custom Extensions:
+ an extreme unlikely outlier).
+* Compliance Testing is straightforward and allows vendors to seek and
+ obtain *multiple* Compliance Certificates with past, present and future
+ variants of the RISC-V Standard (in the exact same processor,
+ simultaneously), in order to support end-customer legacy scenarios and
+ provide the same with a way to avoid "impossible-to-make" decisions that
+ throw out ultra-costly multi-decade-investment in proprietary legacy
+ software at the same as the (legacy) hardware.
+
+-------