Despite that the warnings should probably be fixed, I don't think there is need for a naming policy. I'm sure any guideline will contradict someone's habits or preferences, and will be difficult to maintain.
The guideline would need to be just that; a guideline that a library maintainer would be free to deviate from. But if there is no guideline at all, then every time a user wants to submit a pull request to fix the shadow warnings, it has to be preceded with a discussion about what to use for the particular library. So at least the community maintained library should try for consistency.
Besides it's not clear what to do with tons of written code - starting a new convention without converting the existing code is hardly an improvement.
As for the particular issue, it's probably better to mangle the global variable names (my preference is "g_") rather than function arguments or local variables. Globals are much more rare and their names should be chosen carefully anyway.
The "globals" being shadowed are often in the unnamed namespace in user code. So they involve simple names like "n" and "str" which often clash with parameter names, but the library developer has no control over them. --Beman