Thank you for the detailed explanation. I have some different ideas:
1) "intrinsic value of scores gets lost" is NOT important in most use cases I can think about.
Because when you do Z*STORE, you usually want to get the result in ANOTHER key, i.e. the original value is not destroyed anyway. If you need the score of a value in the result, simply refer to the original sets! Similar to SORT's STORE parameter, I found (pls correct if I am wrong) that the STORE parameter will always store the result into a LIST no matter the key being sorted is a set or what. In this sense, I think it is even very beneficial to allow set-alike operations on different data types, for example, SDIFF <set-a> <zset-b>, which returns a LIST.
However I realize that this might be crazy as the underlying data structure might not allow joint operation on different datatypes. Hence I suggested to add data type conversion commands AND a universal version of "STORE <key>" parameters, which basically solved the problem.
2) Mimic ZDIFFSTORE using ZUNIONSTORE is not reliable and the behavior is not at all same as ZDIFFSTORE. Because you are relying on the *meaning* of the WEIGHT in *different* zsets. Consider the following example:
We have a population, which has 2 parameters: "age" and "income". 2 ZSETS stores info about the people, i.e. age_zset using age as score and ID number of the person as value; and income_zset using income as score. Now I want to get a list of IDs who has their age registered, but income is unknown. How to use ZUNIONSTORE here?