I'm always torn when we change these kind of notes. I don't agree that this will lead to security vulnerabilities. It depends on your threat model. So the "may"/"can" formulation is for me the correct one.

What I do find correct however is that untrusted input can lead to security vulnerabilities. I would honestly drop the "easily" part as again it depends on where the untrusted input comes from. For instance, the user can supply an arbitrary string, and that arbitrary string is processed with (highly non-trivial, but still polynomial-time evaluable) reversible transformations that eventually output a string that is then evaled. In this case, you can consider that you have a security vulnerability, but not necessarily "easily" achievable (but still achievable if you spend time to reverse the transformations).

These warnings are aimed at educating people who don't understand the risks. I'm in favor of leaning more on the scary side. You are correct that the threat model matters, which is why I changed "will" to "can easily". I'd like to keep "easily" because we are trying to scare people away from these functions. The uninitiated will write code that can easily be security vulnerabilities.

You are also right that you can write code using these functions that are not vulnerable, and you can write code that is technically vulnerable but not easily vulnerable. We only have a sentence or two here, we need to use blunt language. We don't have space for the subtleties you are describing, and the people who need the warnings won't understand those subtleties.

In this case, I'm more in favor of a "can easily" rather than "will" (and thus agree with your suggestions). What I also do find valuable is the addition of "untrusted" term in the text.