Actually, the .ini format might not be as good as just a simple ASCII format (as in, without the Row 0= stuff), because unless the variables can be
stored in RAM as a list of key-value pairs like it appears in the .ini, then all puzzles would have to use the same variables. So, for instance, if we were to use the example format you used here, then we would have to find a good, logical way to adapt all the various types of puzzles to be stored in up to 16 "rows".
Of course, it's not like that's difficult to adapt them. For the puzzle that takes a Username and Password, it could be something like this:
[Puzzle 2]
Type=Log In
Row 0=JOE PLUMBER
Row 1=GIZA
But the point I'm trying to make is that it wouldn't be logical (and it could even be misleading) to always have, for example, 16 sets of data called rows. It would make more sense to me if it had a loose text format so that each type of puzzle could have its own way of representing data. Like this:
<Puzzle 1: Maze>
################
#..............#
#.############.#
#.#........#E#.#
#.#.##.#.#.#.#.#
#.#....#.#.#...#
#.#.####.#####.#
#.#..........#.#
#.######.#######
#......#.......#
#.######.##.##.#
#.#....#.#...#.#
#.#.##.#.#...#.#
#.#.#....#.S.#.#
#...#..#.#...#.#
################
<Puzzle 2: LogIn>
UN:JOE PLUMBER
PW:GIZA
<Puzzle 3: Shoot>
^><vv^<v>
<Puzzle 4: Maze>
######
#E..S#
######
Actually, I would prefer a binary format even more (more compact file, and easier for a program to read), but only if we would also make a puzzle editor; actually going into a file with a hex editor is too annoying.