Alternative format for textual representation of chess variant position

In chess FEN is the usual widely accepted format that represents a position.
While working with chess variants and weird pieces, I identified a few difficulties:
1. With a larger amount of piece types, one character is not sufficient to represent each piece type uniquely.
2. Growing complexity of information that describes a position

W.r.t. 1: 
Take for example the symbol C, and all the known piece names that start with a C: Cannon, Copper, Chancellor, Camel, Cardinal, and many more. It would be convenient to have a second letter to distinguish them.
But if we'd choose 'Cp' for Copper and 'Cn' for Cannon, and we'd find 'CpCn' in a FEN, how would we separate the meaning 'Cp + Cn' from 'C + p + C + n'?

W.r.t. 2:
Within FEN we already handle the castling and en passant information. In a position with a Joker, part of the essential information would be which other piece the Joker is inheriting from. A Time Thief, which has the potential of restoring the entire previous position, a lot of information about the previous position should somehow be embedded in our description of the current one.

For my board painter and my WeirdEngine, I am using a format that addresses these two difficulties. And it has an additional advantage: it also represents the position 2-dimensionally.
To illustrate this, here are two positions with a simple tactic that win a Queen:

First position in FEN:
8/2k3q1/8/2N5/4K3/4P3/8/8 w

Second position in JSON:

I suspect that most readers can spot the tactic by just looking at the second representation, and the first representation doesn't help in the same way.

Here I call it JSON, this is the widely known name of a widely accepted format in IT that naturally expresses anything you want.

Here are examples of how this addresses the difficulties pointed out above:
https://github.com/evert823/chess_variant_boardpainter/blob/main/positions/kr_nn_2char.json

https://github.com/evert823/chesspython/blob/main/unittests/11E_Joker_Hunter_1.json

https://github.com/evert823/chesspython/blob/main/unittests/10C_timethief_mate_1_white.json

True, FEN is not nearly as convenient for chess variants as for orthodox chess. Conventional solution to the multi-character piece IDs is to comma-separate the IDs. This is for instance used in the TSA Middle Shogi Manual. In WinBoard I allow diacritical symbols to follow a letter to stretch the number of piece types that can be handled. C, C', C", C! would all be considered different (white) pieces in FEN. This avoids parsing problems that would arise when you allow multiple alphabetic characters in a piece ID, and allows keeping the upper/lower-case convention for distinguishing white and black pieces.

The color convention fails in multi-player variants, as there are only two typographical cases. A solution called DEMN would concatenate FENs for each player (with # as separator) in order of their first turn, so that there is no need to distinguish piece color by case.

Note that FENs are designed for describing board positions, and not really for describing the full game state. Having castling and e.p. info goes a bit in that direction, but even in orthodox Chess the game state contains the game history since the last irreversible move, needed for detecting repetition draws. It is true that some variants need extra info to make a FEN description of any use. E.g. in 3check one should record the number of checks, in Chu Shogi whether the previous move captured a Lion.

I have some reservations towards considering easy interpretation of the description by humans as an advantage. FENs were designed to have compact description that fist on a single line. For actually showing the position one can use a diagram. Making a diagram from text ('ascii art') is a bit 20th century...

That fixes it indeed. I had noticed B~, R~ and Q~ in the diagram editor on the chessvariants pages.

To respond to your last remark ("Making a diagram from text ('ascii art') is a bit 20th century"), I must add that this text format is not 'the diagram'. It's to enable humans to provide input to a tool that will make the eventual diagram. Very convenient in some situations or when it's just what anyone likes most. Other tools will resort to mouse and screen, dragging and dropping, or pasting FENs from somewhere.

Indeed, the Diagram Editor uses FEN-like notation in the query string. This notation allows multi-character piece IDs, (namely the filename of the piece image), by parenthesizing those. This is great for variants that use an occasional unorthodox piece, but gives very long strings when most pieces are unorthodox. So I used shortcuts for the most common unorthodox pieces, using the letter + symbol system. And I tried to assign those in a way that is easy to remember. So a tilde as suffix always means the piece is the knighted version of what the letter would mean: B~ = Archbishop, R~ = Chancellor. Likewise a single quote adds Wazir moves, a backquote Ferz moves (B' = Dragon Horse, R` = Dragon King).

This is basically an 'under the hood' thing, hidden from the user during intended use: to create a diagram the user would just draw piece images from a table to the board squareswhere he wants those, and will then get to see an image of the whole diagram (or the URL that would deliver that image) that he can copy-paste to where he needs it.

I am not sure whether there still are many people wwho like it very much to have to type a board position as text. (The Diagram Designer on works like that.) This is why I used the drag-and-drop system in the Diagram Editor.