Two extra features

I don't understand the use case of any of the suggested features:

As for the first one, I can only guess what is requested: Field names (headers) in csv files are compared with existing the machine name of existing field names in the db. I.e.: A match the csv file's fields with the machine name of the db's fields is what is done. This already allows headers in the csv file to be combined with field machine names in the db. This feature is already in place. My guess is that you're not happy with the machine name match, and want to match the field's human facing name. If so, I don't see the use case for this. I understand that it is convenient for sloppy site builders to not having to look up the field's machine name, but that's not really a use case. We need a much better explained use case to consider this.

As for the second one: We already test for existing user, and if that user exists, the import row is rejected. There is AFAIK no risk of overwriting existing data. This is already in place.

I am giving this two weeks for you (and others) to profide more info in case is is something I've missed. If no new info emerges, the status will be set to "Closed (works as designed)".

I have just tested User CSV Import. There is no doubt that it is useful, but…

Field names in the db are required and cannot be changed. Field names (headers) in csv file can be very different, not necessarily field names, but simply "Name", "Address", "Phone", etc.
I often receive csv files with many names that are either new to the db or just updated. The csv files come from different companies that (believe me) have very different attitudes about column header names.
In User CSV Import, I have to teach my staff raw field names in advance instead of asking them to concatenate column headers with the db's field names.
It is inappropriate and time-consuming to have to go through that process. This is what was better in User Import and what is desired in User CSV Import.
I expect "name" to be unique as well. It will be difficult for the office staff to see through it.
In User Import, username (name) could be formed from the user's name. (Also wish for feature).

In User Import there was a test of whether users who are already in the db were imported. If that were the case, one could e.g. manage to exclude (or accept) these users.

The csv files come from different companies that (believe me) have very different attitudes about column header names.

I believe you. And they also have very different attitudes about what constitutes valid values in CSV rows. To create program code that correctly sorts of this type of fuzziness in data input is very hard (and that's why User Import consists of such a twisty mess of code snippets, all different). As the saying goes: GIGO. Unfortunately, there is no substitute for teaching your staff or your external data providers strict rules about what constitutes valid data, and use a input program that is designed to reject anything that is not valid. To use fuzzy logic to second-guess what bad input is supposed to be is most likely going to put a lot of garbage into your database.

If you really need this, you need to create a preprocessor that sanitizes the input according to the fuzzy logic that applies to your organization and use it normalize your input data before feeding it to User CSV Import. I see no merit in trying to get this working in the general case.

In User Import there was a test of whether users who are already in the db were imported. If that were the case, one could e.g. manage to exclude (or accept) these users.

Yes. And that's a feature request. I asked: What's the use case of this feature request? Ie.: When will it be useful? And what purpose will it serve? (Beyond "nice to have").

Both points are "feature requests".

I guess User Import checks the columns one by one and reads the first line (the header) of each column.
In any case, User Import lists the individual column headers and can be linked to the actual field names.
If there was no header in each column, you could choose to combine column number NN with field db_NN, etc.
When a csv file contains headings in the first line, it will be the headings and not the column numbers that appear as column NN(heading)
I don't know if User Import has a lot of weird code for that, but it should be doable.

(I can suggest installing User Import in the D7 and as a general user check out the good facilities that are there.)

In my organization, overwriting user data can be fatal. I wouldn't say "Nice to have" but "Practical to have" as it has also been a time saver.

It is not a question about whether it is doable. The question is: Why should it be done? To do it, I must take time off from paid work and do a lot of coding where there is no discernible benefit for this project or the majority of this project's users. This is not something I am going to do. (I understand that you think it will benefit you and your company if I did, but unfortunately, that's not really fits the definition of a use case.)

User CSV Import does not overwrite user data. As already stated, if the user already exists, new data is rejected, it is not overwritten. There is no need to "request" something already in place.

I do not understand what use case this feature request is supposed to bring to the project.