"WAFL writes data in a round-robin fashion to the RAID groups in a volume. Data is written to one RAID group at a time, one per consistency point.
It looks like there are notes in the course you took that need updating. Sorry about that.
This was true in the earlier MV/MR capable ONTAP microkernels circa 5.0, but this isn't how things have worked for some time (around two years would be my guess). The above methodology created performance issues when one RAID group in the system was of dimunitive proportions. Things now work in a much more balanced manner across all the RAID groups in a volume, virtually eliminating the need for customers to be overly concerned with or even aware of such matters, which is of course how it should be.
o Is it even a good idea to have more than one RAID group per volume?
The rule of thumb is that the filer's defaults rock. Unless there is something particularly exceptional or peculiar in your environment, I'd leave them alone and just let Data ONTAP do its job. It's an expert! :-)
Say I fill up a volume on a 14-disk RAID group (12d+1p+1hs), and then I add two more shelves (13d+1p) in another RAID group to expand this volume. (This gets rid of the RAID group size imbalance that will definitely result in poorer performance, which is the next subject discussed after the quote above.) Say I continue to add data to the volume, and as is likely, the last added data is probably the most often used. Will I have a "hot spot" in the second RAID group with the consistency points, since I'll be doing lots of reads and writes to the new data and very little to the old data?
Probably for a while, but it's not really as simple as this. As time goes by, WAFL's copy-on-write habits would tend to "move" data that is in the first RAID group out into the second, at least for a while. For example, the metadata associated with the "old data", inodes that contain changing last access times, metadata files in general and the pointer blocks that track them and so forth, would tend to be hauled out into more spacious surrounds as WAFL's tree-'o-blocks structure changes. Even such things as snapshots cycling out of the system would likely create some decent expanses of room in that first RAID group not long after the second was added. There's all kind of things to consider, but in the vast majority of scenarios you should ultimately wind up with a very well automagically balanced state of affairs.
I believe your other questions were made moot by my telling you that the old round-robin algorithms are a thing of the distant past?
Keith