Thanks for testing - that notation (surrounding with quotes) is already known for example in Dynamic Validations - so I think is just OK as is

1. I tested other global context variables such as @#Date@ or @#AD_Language@ and found out that when these variables aren't numbers themselves, the system fails with a Postgres exception (ERROR: column "en_us" does not exist).
When examining the created sql, we can see why it happens:
SELECT SendEMail,
C_BPartner_ID,
...
(en_US) AS TestValue,
Created,
WHERE ...
In the above test, we can see that (en_US) is the content of @#AD_Language@ and it is being taken as a column name on the database. I, then, went ahead and tested it by surrounding the column sql field with simple quotation marks as in ('@#Date@') or ('@#AD_Language@'). The column was shown successfully.
2. I also tested it against an info window column and the results and workaround from (1) also apply.

¿What would it be better, to add documentation explaining that this feature might need simple quotation marks or to add code to detect global context variables and automatically add quotation marks?

Tested:

• using @#AD_User_ID@ in virtual column

• searching the virtual column

• printing the virtual column

Untested but must work:

• using the virtual column in an info window

• using the virtual column as display in a reference