The APL language used a unique set of characters, and additionally allowed overstriking of some characters on the terminal to form characters that were used in the language. When an APL workspace was saved, or a function with an overstrike was executed, were overstruck characters (e.g., 'domino' [matrix division]) saved as a single token, or as the three-character sequence quad,backspace,divide (or the reverse)?
It's important to keep in mind, that there weren't that much symbols using overstrike in basic (IBM) APL. By using an 8 bit codeset they all could be integrated. The most common charset on the mainframe side was Page 293 which extends EBCDIC with all (at that time) legal APL codes.
With APL2 code handling became more complicated and Page 293 was replaced by a combination of an arbitrary base Page (nowadays Page 037, the EBCDIC equivalent of ISO8859-1) used for text and a separate page for APL symbols, Page 310. Page 310 holds all original APL symbols at the same encoding as Page 293, but replaces the letter blocks with 'new' APL symbols as well as making the decimals superscript. Page 310 is, despite its alike organization, not an EBCDIC page, but a strict graphical supplement, not usable on it's own. Keeping the (APL1) codes at the same place simplified loading and conversion of older programs.
I was once writing an APL compiler (never finished, having figured I could single-handedly write a compiler in a 10 week undergraduate programming project), and the choice I made was to have an internal 8-bit character set where each composite symbol was a single character. This seemed an obvious choice to me, since that way you're separated from how that symbol is represented on any particular external device.
The thing was supposed to be portable, but my development system was on ICL 1906A, with an impoverished 6-bit character set, and accessed through teletypes with a standard typehead. So my pro tem external representation used two-letter abbreviations preceded by dot. I might have picked .MD for the matrix-divide operator, for example. But only the lexical scanner needed to know about that. If I had ever had a better terminal, I would just write an alternative lexer.
I see your title explicitly asks about IBM implementations, but I think a description of alternative system might shed a little light. Fundamentally this feels like the same solution as the IBM one -- define the character set you need, and then translate to/from the devices you've actually got (which, if you have a fancy terminal that I did not, might be done by installing extra character sets in your fancy terminal).
IBM had several different APL mainframe implementations, and they where updated and modified over many years to support different types of hardware and I/O equipment over their life time. The source for one of the earliest APL implementations for System/360 is available from the Computer History Museum. As far as I can remember they assign unique codes to the overstrike combinations when they are identified in the input buffer, before processing by the actual interpreter. One obvious reason for this is that you do not want the encoding to depending on the order of the overstruck characters. Another reason is that different terminal types provide the characters in different ways. Some types of 3270 (APL) terminals would let the user perform a kind of overstrike operation on the keyboard, but only store and transmit the composed character from its buffer.