I know that is difficult to extrapolate the tone when you read a content, so don't worry :) I am also sharing opinions here, if there was a fixed way to address this I will point to the documentation link and all good :)
If your DB architect wants that prefix there is nothing I can't do :) Let's say you have 50+ zip files that contains the exports of this solution during the last year. How this DB architect is planning to store these files? if you store inside a folder (I am doing a folder example here, but it can be of course a source control repository) with another 1000+ files having SOL as prefix you can find it easier, but I would put that kind of files in a specific folder (or repository). If the DB architect says "I want they start with SOL so they are a solution file" let him do (maybe is worried that the extension is too generic, opposite for example to a .docx or .xlsx)
Regarding the DEV name, you put your name inside 3 solutions and you were the solely worker on these components. 1 year later you go to work for another company, the person in charge of the 3 solutions you created has a very little advantage to know that you were the one working on that. My point here is: if you want to track who did something inside the system, adding the name inside the solution doesn't help. Keeping some kind of log (for example inside an excel file) and you can have something like:
15-Jan-2021 | Lucas H | added fields X, Y, Z to Account Entity and Forms A, B
16-Jan-2021 | Lucas H | created new View "My Custom Account View" under Account entity
and so on
(just a note, this kind of log maybe be useless when there is a document already that specify what are the customizations that should be done, customer X wants A, B, C and you provide this functionality inside Solutions X and Y, from your post I have the feeling you are working for an internal CRM, so you will need to keep the log as a document that specify the customizations is absent or incomplete)
Also the Description field of a solution is limited (I don't remember the exact number right now, maybe 4000 chars?) and you can easily fill it up with a generic change even for few solution changes
Maybe in your case the goal of the solution should be put inside the description field, so your solution name will be "NewContactViews" but inside the description you write something: "The solution has been created to address the following needs: 1) New View called "My Regional Contacts" bla bla bla 2) New View called bla bla bla"
Regarding Versioning: You should rely on versioning. I don't care if you do unmanaged/managed, if you plan to do patches or not. You start with version 1.0.0.0, when you feel that your solution is ready to be moved to TEST (or PROD) you export the solution file, import in TEST (or PROD) and in your DEV instance you increment to 1.0.0.1.
Or if you have another approach, let's say that in addition to when you move the solution to another instance you also export the solution every Friday at 5PM, before this export you increment the number.
Keep in mind that of a solution you can only change the display name, not the solution name itself. Do you want to put the version inside the zip file? then create a simple bat file (or whatever you think is convenient in your pipeline) to rename the zip file, but the version number of a solution is important, if you don't change it you can't know the exact version you have in a specific environment.
