“The most useful definition of homoiconic IMO is that the internal representation of the language (the AST) is the same as the external representation of the language”

Except this is never true, unless your AST is a string. And Racket’s internal representation (syntax objects) is much more complicated than what is apparent from the text. So, in my opinion, defining homoiconicity in terms of the textual syntax is basically impossible. (And I’m sympathetic to Shriram Krishnamurthi’s claim that homoiconicity doesn’t mean anything).

The interesting property, in my opinion, is that languages like Common Lisp are not specified in terms of the textual syntax and so the textual representation is irrelevant to the semantics of the program: a visual tool that produces lisp forms is as valid a “syntax” of Common Lisp as the standardized textual representation produced by READ.

"Homoiconic" means that code definitions are stored in the original textual form, or possibly in a tokenized form from which the text is easily recovered. Thus the program's definitions may be edited, without referring to external source code.

Bash is homoiconic because you can type "set" with no arguments, and see all the function definitions in their original syntax (albeit reformatted and without comments). You can copy and paste these definitions, editing them in between.

In Common Lisp, the perhaps little-known ed function supports homoiconicity. Function definitions whose original definitions is available may be edited. (Like Bash's set, ed will serve you up a reformatted function without comments.)

Homoiconicity is mostly stupid and irrelevant, and an earmark of immature, naively implemented languages. A Lisp which compiles every definition that is fed into it, throwing away the original nested lists, cannot support a function like ed, and fails to be homoiconic, yet has all the oft discussed advantages of Lisp.

A feature that is close to homoiconicity that is useful is a REPL with history recall. In a REPL with history recall, we can write definitions. Even if those definitions are compiled, so the language image has no record of the code, the REPL has the original text in memory. So by history recall, we satisfy the use case of the programmer who wants to recall a definition, edit it and replace it. Or some of those use cases. Obviously, a program doesn't come with a REPL history of its definitions; only one that we made in the REPL.