+There were several solutions offered that fell into this category.
+A few of them are listed in the introduction; more are listed below,
+and it was exhaustively (and exhaustingly) established that none of
+them are workable.
+
+Initially it was pointed out that Fabless Semiconductor companies could
+simply license multiple Custom Extensions and a suitable RISC-V core, and
+modify them accordingly. The Fabless Semi Company would be responsible
+for paying the NREs on re-developing the test vectors (as the extension
+licensers would be extremely unlikely to do that without payment), and
+given that said Companies have an "integration" job to do, it would
+be reasonable to expect them to have such additional costs as well.
+
+The costs of this approach were outlined and discussed as being
+disproportionate and extreme compared to the actual likely cost of
+licensing the Custom Extensions in the first place. Additionally it
+was pointed out that not only hardware NREs would be involved but
+custom software tools (compilers and more) would also be required
+(and maintained separately, on the basis that upstream would not
+accept them except under extreme pressure, and then only with
+prejudice).
+
+All similar schemes involving customisation of the custom extensions
+were likewise rejected, but not before the customisation process was
+mistakenly conflated with tne *normal* integration process of developing
+a custom processor (Bus Architectures, Cache layouts, peripheral layouts).
+
+The most compelling hardware-related reason (excluding the severe impact on
+the software ecosystem) for rejecting the customisation-of-customisation
+approach was the case where Extensions were using an instruction encoding
+space (48-bit, 64-bit) *greater* than that which the chosen core could
+cope with (32-bit, 48-bit).
+
+Overall, none of the options presented were feasible, and, in addition,
+even if they were followed through, still would result in the failure
+of the RISC-V ecosystem due to global conflicting ISA binary-encoding
+meanings (POWERPC's Altivec / SPE nightmare).
+