I filled out the  RISC-V Policy: Change and Extension Rationale
as best I could for the issue #427. I believe it is accessible by all. But I will also paste the contents below.

https://lists.riscv.org/g/tech-vector-ext/files/Change%20Extension%20Rationale%20Submission%20For%20riscv-v-spec%20issue%20%23427.docx

Name: Change and Extension Rationale Submission for ricsv-v-spec issue #427

1. David Horner

2. In GitHub riscv-v-spec issue #427 originally April 21,2020;

   Closed: July 24; reconsideration July 30;

   As Change Rationale Aug. 6,2020

3. Individual as memeber of Vector TG.

4. August 2020, prior to V1.0 submission for ratification

5. The Kickoff and/or Freeze Milestones.

   Idoes not need Roadmap visibility.

   It is a refinement to a set of Integer Widening instructions.

6. List of questions please explain your answers where appropriate (like why did you say yes):

   1. Not a functionality gap? Rather it is an apparent formulation that can improve application performance by avoiding vtype mode shifts.

   2. A horizontal attribute enhancement affecting performance.

      Twice the standard integer scalar range is available for widening integer instructions.

   3. No change to ratified ISA specification, Vector extension in progress.

   4. This request is for a completely new rendering of proposed Vector features.

   5. This can be done with already proposed instructions?

      In general it requires:

      i) executing the current widening with integer identity value

      (1 for multiply, zero otherwise)

      ii) mode switch to twice current Selected Element Width (SEW)

      iii) perform corresponding adjustment on step i) widened vector results

      (multiply by or add/subtract widened integer value, as appropriate)

      iv) mode switch to original SEW.

   6. Users/markets which benefit are restricted to V users

      in which 2*SEW integer values are handled in widening scalar ops.

   7. No expected to affect base or derived or custom profiles ?

   8. Compliance tests and compiler generation will need to handle an enlarged integer scalar register.

      1. No changes in the number of cycles needed for any handler entry and exit, and changes in the number of save/restores required.

      2. Changes required to support this extension are typical of other vector instructions tweaks,

      3. No known resources who have time to implement either or both of the above to work.

   9. I expect the impact on logic/gates to be small. Less invasive that ordinal based mask encoding. Much less disruptive than removing SLEN visibility. More comparable to the mixed width vrgatherei16 instruction that is being added.

   10. It would not be optional.

   11. It is no more discoverable than any of the other base vector instructions.

   12. Concerns for widening multiply were the problem of leveraging the multiply units needed for the next higher SEW for the current SEW. Concern is that the SEW level multiply unit will have to be enlarged. Initial estimates were by a factor of 2.

       Given that the multiplication result is widening to 2*SEW, some of the needed circuitry already is present for an expanded integer input. The expanded multiplication result will be truncated to 2*SEW, and so, for these teo reasons doubling of the circuit is not required. As a result a mitigation that dynamically selected paths based on zero (or sign extended) upper SEW integer bits is not required. Such a scheme was correctly rejected as inappropriate for most implementations, but it does not materially factor into the discussion as partitioning the next higher multiplier circuitry should be adequate for all anticipated implementations.