Having different ideas is good; agreeing from the start would have no added value.

Ok, I certainly can't argue with that :)  This is definitely an idea worth pursuing.  It would be great if there were a common "game definition format" that is accepted by multiple engines and GUIs, even if it didn't address the more exotic variants.  Of course, our programs could also support "internal" variants - special games handled at a lower level either because it is necessary, or simply because the engine could be stronger if optimized for the given game.

What I am afraid of with the game-definition format it to fall victim of the "maximum-flexibility-minmum-usefulness principle". The overwhelming number of Chess variants and fairy pieces are very simple, and it would be a pity to force an enormously complex description system on the user to describe these, just so that it would also be possible to describe something very complex that they are never going to need.

Indeed, I completely agree with this also.  It's a challenging problem, and a difficult balance to strike, but that's also what makes it so fascinating!  And that is probably why you and I have both spent so much time pondering this problem for well over a decade :)

And it is always possible to use a basically simple format, like Betza, but define some 'escape' symbol that allows you to use a Turing-complete programming language to define what you want.

Yup.  I also agree that this problem is best solved with a multi-level approach.  If you want to make a "modest" variant that should be very easy.  Recent example: Hanibal Chess - Chess on a 10x8 board adding two FAs.  But it should also be possible to handle more complex things.  Another recent example, same author: Wide Chess - this could have been simple, but made complicated by the fact that, when castling, the king can now pass over attacked squares.  And, ideally, it should be possible to address things like this without having to resort to resort to really low-level ugliness (by analogy, the equivilant of dropping from JavaScript to in-line Assembly.)  How do we best square that circle?  THAT is probably the single biggest thing we need to figure out.

To maximize our chances of success, this should probably go beyond open forum discussion to something more formal... For example, find out who the interested parties are.  Then, before getting into details, come up with a formal statement of what the hell our objective is.  Then, we should each become at least somewhat familiar with the existing approaches we have already pursued or proposed to see the pros/cons of each.  The Betza 2.0 approach, for example, is *radically* different from the ChessV approach - which I will call the "inheritance" approach - where you define your game by picking the closest game, deriving from it, specifying only how your game is different.  (There are also abstract base "games" underneath everything, even Chess, from which you can derive.  Actually, there are several levels of abstract bases, each offering additional functionality, with configurable switches to deactivate and/or configure the new functionality.)  Our approaches are so different because of our backgrounds.  I'm a practitioner and true believer in object-oriented programming for about 25 years now.  You're not an OOP guy, so of course we think about these things completely differently.  Which is better?  Who knows.  Hopefully the best of both can hapilly co-exist.  Evert Glebbeek will be a valuable addition here since he has taken a middle-road.  He clearly understands and uses OOP, but hasn't gone nearly as far with it as I have.  Then there's yet another paradigm, Functional Programming (e.g., Lisp, OCaml, Haskall.)  I suspect this paradigm has a lot to offer in addressing this problem, but my brain just doesn't work that way, despite the fact that the University of Florida tried to teach me Scheme when I was 18 years old...  at the time, I probably wasn't open-minded enough and now, much later in life, I've tried but it's too late to start thinking that way.  Incidentally, the Zillions-of-Games definition language is basically Lisp, a Functional language, but theirs isn't a very good solution because they did not take a multi-level approach.  (NOTE: I do not mean to disrespect ZoG, they were the first people to ever attack this problem, and given that, what they were able to accomplish is nothing short of incredible.  It's a shame that they all completely disappeared.)  Sorry for the long-winded digression, what I'm getting at is that we should take some time to see what has been done and understand where we each are coming from before we get too deep into where we should be going.  A next logical step would be breaking it down into specific questions/ideas and studying those.  And what these questions/ideas should be won't be obvious until we've each looked into and thought about the work that you, I, Evert, and others have already accomplised.  Anyway, what I'm suggesting is that, to really accomplish this, we should have a process that is slow, deliberate, and formal.  Open-forum chaos isn't likely to grow the desired fruit.

What I would propose as a first step is to start a new thread on TalkChess (a more appropriate forum for chess programmers than this) proposing formation of a "working group" of interested people to work together to study this problem and work toward a solution.  This working group would, of course, include you, me, and Evert.  Possibly others who have worked in this area might be intersted, like Daniel Shawul.  We might also need to exclude people in the event that they want to jump in but have not worked in this area and have nothing to offer.  This will be difficult enough without disruptive influences.