I suppose this behavior could be interpreted in different ways. My reasoning for believing it is the wrong behavior is:
1) Scanning behavior shouldn't guess what to do. It should react predictably and consistently. "10k" itself works, but "10kOtherText" does not. This is inconsistent.
2) The "%p" format string specifies that the number may include SI prefixes. Any case where a prefix (like k) is ignored is wrong.
3) If the desired behavior is to separate the number from any SI prefixes and other text, %g, %e or %f formats could be used, along with additional code to parse the remaining string as you suggested. The existence of the "%p" format code indicates that there is a better way to read SI prefixes.
4) There are some format strings that will always be impossible to interpret. For example, "%pm" for SI prefix with meter units. "10m" could be interpreted as 10meters or 10millimeters. For ambiguous inputs like these, the best a scanning algorithm can do is be consistent. Having "10m" be interpreted as 0.01 while "10mm" is interpreted as "10" is not consistent.
I have no confidence that this will get fixed since it would change the behavior of existing code. However, I think this post will provide feedback to NI and other developers about this behavior.
Scan to string doesn't work well with the %p (SI Notation) format string. If the input string is "10.0k", the string will be read correctly as 10,000. However, if the string is "10.0kHz", then the resulting number is 10. It should be read as 10,000 and the remaining string should be "Hz".
