I am also looking forward to a future release of this, which will populate the rooms based on the rest of the subtables. If I don't see a faithful implementation of "TABLE VIII. C.: MAGIC POOLS" (e.g. roll 16-17 on a D20 and get "Talking pool which will grant 1 wish to characters of its alignment and damage others from 1-20 points.....") I will be gravely disappointed.

The plan is to populate the rooms in the future :)

Iteration, I'd imagine.

1. Generate a pile of random rectangles. This is an additive operation (this is only important for #4, below).

2. Check to see if any overlap. If they do, remove one.

3. Repeat 2 until no more overlap.

4. Check to see if there are too few rooms in the map. If there are, go back to 1.

5. Add corridors (this is a whole 'nother topic).

This is an appealing algorithm; its only flaw is irrelevance to the case at hand. Our original poster is proudly following Appendix A of the venerable 1st Edition Dungeon Master's Guide, which essentially is a breadth-first search with corridors generated 'as we go'. This is not to say that your proposal is worse; just that it fails to capture the early-80s grognard magnificence that the designer appeals to be looking for.

Actually, I resisted making it purely breadth first since it would result in more of a dungeon crawl that a sprawling dungeon. However, I might offer this as an option in the future. It's not a difficult modification to make.

Good question.

Whenever the program goes to place a room or corridor, it firstly checks whether those squares are unoccupied. If not, the room/corridor isn't placed.

I originally made it place the room anyway, since it might result in some interesting structures. But in practice, it just made a complete mess and there was no easy way to decide when to make the algorithm stop.