I have to admit that the functionality you described under point 1 is not even known by me.
...but we are not using this return vendor flag for several reasons.
Our return process is supported by an own developed application. We actually have that few returns that always a consultant was needed to explain what master data has to be extended until it could be posted successfully
It is not seldom that a vendor is as well a customer to us, hence this customer master exists already and we have to avoid that a duplicate gets created unintentionally by setting this flag.
From this points of view I would actually say that your described functionality is dangerous to us
as it brings an inconsistency in the data maintenance processes.
And...we have a central master data team who is responsible for the general data, a buyer is not allowed to create this data, it has to be requested via workflow to ensure the correctness of address and tax data and to avoid duplicates
This LFA1-KUNNR is as well used for other processes like subcontracting. Do you then enter the customer number manually or do you set the returns vendor flag to get it created automatically?
I agree that some old programs could deserve some restorations, I desperately miss a BAPI for vendor and customer load. I usually load with IDOCs and here you are certainly resricted to the object itself. E.g. I have to load my main vendor data with CREMAS Idoc followed by ADRMAS Idoc to create the central addresses. And here even the field lengths for the address fields are different.