Thanks for the report, and the feedback. I wonder if you can give a little more detail on how you are using the ComboBox - if you are using it to store and filter Strings, I have another suggestion that might make sense.
Make is a ComboBox<String>, and instead of trying to tell the ComboBox that the new string is merely not an error, give it a custom PropertyEditor<String> instead. The purpose of a PropertyEditor (the name is a holdover from 2.x, before there was such a thing as the Editor framework) is to turn the text the user enters into a value that can be used from code, and vice versa - how to print the values from model objects into text on the screen.
The default PropertyEditor for ComboBox (actually for the ComboBoxCell) is ComboPropertyEditor - it uses the protected method T selectByValue(String) to try to figure out what value in the store matches the current string.
If, as I said, you want to support any string value, this is a great way to add a value to the Store if it fits, or to just say 'yep, that string is a string, and strings are values' - no need to test against every value in the store.
That said, yes, our current behavior on clearValueOnParseError=false clearly doesn't make sense, and it is quite possible that forceSelection doesn't make sense given the differences between 2.x and 3. I'm currently focusing on how we can make clearValueOnParseError work - and trying to ensure that it will be enough to satisfy the forceSelection behavior.
Merging two threads to allow discussion on these two setters and how the PropertyEditor can be used.
I'm currently of the opinion that if a non-matching value is entered, it should be drawn as an error, and clearValueOnParseError and forceSelection *only* govern what to do with regard to the old errors. ForceSelection=true would avoid the issue by selecting some value (last, or closest match), and if false, then either the string should be retained or cleared (clearValueOnParseError). If you want the value to be not only kept but made available from comboBox.getValue, then a new PropertyEditor is in order. Thoughts?