Is it a security vulnerability to tell a user what input characters are valid/invalid?
... that could be useful in an attack but is normally not available to the attacker
Knowledge of invalid input characters are useful but can easily be found by the attacker with just a few tries. Thus this information is not really secret and keeping all users unaware of what exactly went wrong does not actually deter attackers, it only keeps innocent users away since they cannot continue.
Creating a psychologically frustrating situation for users could incline them toward less secure decisions. For example, they try to write a password in Swedish, but your input refuses the character å without explanation. Instead of picking a different good password without å, they throw up their hands and use password123—one that's easily defeated with a dictionary attack.
Thus, you have attempted to create a "more secure" system through obscurity, but once we account for user behaviors, it is in fact less secure.
Valid characters are ultimately discoverable through systematic means. Hiding them is not worth the damage you might do to user behaviors.
For further reading, see "Security and Cognitive Bias: Exploring the Role of the Mind" and "Measuring the Security Impacts of Password Policies Using Cognitive Behavioral Agent-Based Modeling" by Sean Smith et al.
It depends.
If the message describes an error from the normal users point of view, like "The 3rd character must be a digit", it is not a security vulnerability. But displaying regular expression used for validation means disclosing implementation details which can be a weakness, e.g. some libraries use recursive calls extensively and some expressions can cause stack overflow or high memory and CPU usage, which may lead to DoS.
The CWE-200 defines disclosure of information as a weakness only if user is not explicitly authorized to have access to that information. You are considering user input. Means, user is allowed to enter this information and thus allowed to see this information and naturally he is allowed see any validation error messages related to this input.
Stack trace as well as other technical messages can provide information about the technologies used in the application (e.g. what version of what libraries are used), about the environment (e.g. directory layout and permissions, OS type and version), etc. An attacker can use this information to effectively choose exploits for these particular technologies, libraries, OS, etc. That's why disclosing such information to user is potentially a weakness.
Not explaining the user what is wrong in his input is definitely bad UX, but not security improvement.
Don't confuse that with similar cases, when data is sensitive and any validation related to it can be sensitive. For instance, if user entered letters in the field where you expect a year, then explaining such error to user is safe. But if the user enters an email address and you check if such address is registered in your system, then any information (address is known, address is unknown) can be a weakness. That's why when you are going to implement validation messages or any other feedback regarding user input, evaluate the consequences. But prohibiting any feedback by default for all fields can be a poor UX with a false feeling of security.