** Using WeBWorK **

Once non-ASCII unicode character are allowed in input fields, you should be able to process them via MathObjects by defining the proper values in the context (as Mike suggests). Moist of the name patterns would need to be changed, however, as they currently only allow ASCII characters, but that can certainly be done. Something like π to be equivalent to "pi" is easy. Same for ≤. You would need to be sure to include TeX commands for their output, as I don't think latex will handle the unicode characters (there may be a package that allows for that). These could be done with just configuration of the context.

Using ⁶ for "^6" would be possible, but would take making a new class to process the operator, but that can be done.

For ° you could create an operator (right-associative) that multiplies its argument by pi/180, I suppose. If you want to make it work with NumberWithUnits, you would have to define a new unit ° that is equivalent to "degrees", but that could be done.

In the meantime, a hack to get it to work might be to have the javascript code that transfers the GeoGebra data into the hidden input field perform some replace() calls that translate "π" to " pi " (with spaces so that it will not accidentally parse as part of some other word), and so on.

If there is no javascript that does that, then perhaps the submitAction() function could be used to handle the replacements. It could use document.querySelectorAll('input[type="text"]') to get all the input fields and loop through them to modify their values, replacing unicode characters by their equivalent ASCII representations. This would run when any submit button is pressed, before the form is sent to the server, so it should be possible to pre-process the unicode in this way.