"on the semantic side of things" is inherently bad, to my mind. What comes out of the parser should be the way a human would process it if at all possible; in the cases we're talking about, a human would say "na'i" or "ki'a"; I expect the parser to as well.
Ah, but a CFG does not define a parser. It defines a language, that's all. Defining aspects of what ought to come out of a program that is parsing an input is not part of that job. The class of programs being referred to as parsers also generally do not output the same language as they input; they output some other representation of the meaning of the input string. A human would probably take a shot at understanding what the person who made the erroneous/unintuitive statement was saying, rather than stop and give up; why shouldn't a program do the same? And all that it would be doing is taking a set of rules to determine unambiguously what /meaning/ is associated with this string. Requiring the CFG to be unambiguous on every string in the language - that is, to have exactly one derivation - tends to be quite unweildy when all you really want to do is eliminate semantic ambiguity - have exactly one meaning associated with every string in the language.