[ This issue refers to two non-ASCII Unicode characters: U+E9
  (e-acute) and U+1F600 (grinning-face emoji).  Bugzilla accepts
  the former, but not the latter, so in the following, I've typed
  an ASCII "*" in place of the literal emoji character. ]


There is some inconsistency in the register's handling of (what I
believe to be) invalid input.  This isn't new; it's the same in
GNC 3.0 and 2.6.18.

in a text field (i've tested a txn's description and a split's
memo), both U+E9 ("é", e-acute) and U+1F600 (grinning-face emoji)
are accepted, displayed, and stored correctly as UTF-8 by the XML
back end.  OK so far.

But in a currency-amount field (I've tested specifically a
split's Debit field, and all of the following cases are described
in those terms):

        I type          Result
        ======          ======

        abcd<ENTER>     Each of these behaves like "0<WHICHEVER>":
	abcd<TAB>	  - Debit is set to zero
			      - N.B.: this clobbers the previous
				value; compare with "5a<TAB>"
				below
			  - Focus moves as appropriate for
			    <WHICHEVER>

        a5		Same as above

	5a<ENTER>	Nothing happens.  The Debit field
			containing "5a" remains focused, even
			after repeated <ENTER>s

	5a<TAB>		1. I get an error dialog: "An error
			   occurred while processing 5a."

			2. When I dismiss the dialog, GNC moves
			   focus to the Credit field, leaving the
			   "5a" in the Debit field (the latter is
			   very surprising; the former only
			   somewhat so)

			3. When I then <TAB> or <ENTER> out of
			   the Credit field, Debit reverts to its
			   previous value
			     - N.B.: This is unlike "abcd<TAB>"
			       which forces Debit to zero

An e-acute (U+E9) it treated like "5a" above:
        12é34<ENTER>    As for "5a<ENTER>" (except that the cursor
			jumps to just before the offending "é")

        12é34<TAB>      As for "5a<TAB>"

But the U+1F600 emoji is completely ignored: it isn't displayed,
and has no effect on the results:
	12*34<ENTER>	As if I'd typed "1234<WHICHEVER>"
	12*34<TAB>

All of those are invalid inputs for currency amounts, I presume,
so it's to be expected that GnuCash rejects them all.  The issue
is with the variety of forms that rejection takes.

Testing context:
  - Ubuntu 16.04
  - GNC 3.0 and GNC 2.6.18 (same results with both)
  - Xfce (not sure if that matters)
  - Locale-related bits of GNC's environment:
        LANG=en_US.UTF-8
        LANGUAGE=en_US
        LC_COLLATE=C
  - Autosplit Ledger mode in effect for the account in question

  - AFAIK, I'm using UTF-8 (not UTF-32 or the like).  In all of
    the above testing, non-ASCII characters were entered using
    the CTRL-SHIFT-U escape sequence, e.g.
        <CTRL><SHIFT>ue9<SPACE>
    for the "é"