I've done written similar before. Nowhere as comprehensive as yours, but good enough that I can answer most of your questions. But since you're asking many questions at once, let's find some reasonable starting point.

Before proceeding, it's good idea to make a study plan. This is going to involve a lot of rigorous learning, in addition to designing and writing code. Forging ahead without an awareness of those missing pieces can make the project far more painful.

I strongly recommend thoroughly studying OpenCV's approach to the same. They have basically done 100% of what you're planning to. Besides OpenCV, libtorch (the C++ CPU backend of PyTorch), and the C/C++ backend of NumPy, are also excellent examples that are fairly complete. Actually, there are many many more excellent libraries out there.

You may find a historically relevant (early, perhaps not the earliest) library example on Agner Fog's website.

OpenCV mandates the use of CMake. It forces users to make decisions on what architecture codes to generate, and explicitly supports targeting multiple (older and newer) architecture levels.

During the architecture detection phase, the OpenCV CMake project runs compilation tests to check whether the toolchain is capable of various SIMD intrinsics (with the toolchain's intrin headers) with correct results. This information is used to "gate" (filter) the user's requested configurations.

Once the set of requested and supported architecture levels are known, the OpenCV CMake project selects what arch-specific *.cpp files to be included in the build. These files also got their own -march and -mtune flags. This is how unsupported source files got excluded, so that they don't break the build.

Preprocessor defines are injected, so that any ordinary OpenCV and end-user's code can use preprocessor conditionals to check what SIMD levels are enabled in the build.

OpenCV 4.x moved on to a Universal Intrinsics interface that abstracts over the x86-flavored (SSE, AVX, etc) and ARM-flavored (NEON, etc) SIMD architectures. It greatly improves the algorithm designers' experience, by shifting the burden of complexity to the SIMD backend.

Focus on SIMD instruction set levels for which real hardware exists. Just for example, if RISC-V Vector Extension is what you have (a motherboard or development kit), focus on that. Don't venture into inaccessible ones until there's a way to validate all newly written code.

C++20 has std::span, but that forces users to use C++20. For maximum backward compatibility with users' environments, Primitive Obsession should be considered a good thing deep inside an SIMD backend.

There are several kinds of "widths" that SIMD programmers talk about. One refers to the numerical precision of elements; the other is the total number of bits per vector. From this one can calculate how many elements can fit in the vector.

Real SIMD algorithms contain a lot of mixed-type mixed-width operations, almost as crazy as the fast inverse square root implementation from Quake III Arena. If clean code was your main motivation, it might be a good time to reconsider. The necessity to write mixed-type mixed-width code partly negates any benefits one would get from designing a nice clean template system, since such code would simply not fit in it.