Thing 1: There's a difference between an easier world and an easier embark. (People have been discussing elements of this, but it's important to know in order to understand their contributions.) Generating a world can rig the majority of the area easier or harder, but most worlds generated with the "basic world generation" mode have a good variety of embarks to look for. That's typically where the advice about what to search for and avoid comes in.
Thing 2: There's both a world generation parameter set and a pseudo-random number generator seed. The parameter set limits and influences the procedure that generates the world; the seed is where the "random" numbers start and therefore determines the incidentals of how the world happens to be laid out. This means that if the world generation procedure is given both the same parameter set and the same seed it will produce the same world, since the sequence of pseudo-random numbers is determinate starting from the same number. It also means that changing the parameter set and using the same seed is usually not practically different from changing it and using a different seed: because the way the procedure uses the sequence of "random" numbers is different if the parameter set is different. However, you can change the seed to get different worlds with the same parameter set and hence the same general characteristics (or at least, the same likely general characteristics within the same limits), whereas changing the parameter set itself will not only get you a completely different world but one with different characteristics (whether drastically or subtly).
Thing 3: The difference between an incomplete feature or feature set and a bugged one can be subtle, and by extension so can the difference between completing a feature or feature set and fixing it. It doesn't matter so much if the developer really is trying to meet people's needs or expectations -- or at least his own high standards of worthwhileness and not just some sellability factor. Speaking from experience, you will, in contrast, find other people out there who will try to spin obvious bugs -- things where the functionality's logic literally cannot produce the result that is the stated purpose of the feature -- as "being built to the design" such that "if you want it changed that will be an enhancement that will cost an extra [insert large number here] dollars." And if they're really bad, you will never actually get to see the design you're being chained to or have any other proof that they're not making it up off the top of their heads. That's one reason savvy contract-writers have to be so savvy: they've got to ensure that the design is itself required to actually be something that meets the requirements of the customer and that if it doesn't the developer can't hide behind it. Similarly, you need clear designs and good quality assurance testing if you're going to separate development and support internal to an organization, otherwise support is left to pick up the ball whenever development doesn't do as well as they should and inevitably they become better experts at it than the people who actually have power/authorization to improve the thing.
Of course, you could argue that there's a note of similarity to this in Toady going off and developing whatever currently interests him instead of fixing whatever the current biggest bugs are, but there are crucial differences: It's a game and not an application a business depends on, Toady's not requiring us to pay him for bug fixes or for the game in the first place, Toady doesn't pretend these issues aren't issues (nevermind whether they're bugs, which doesn't matter so much if you agree they're issues and should be improved without extra cost), and perhaps most importantly Toady is focused on making the game well for its own sake.
All that was probably more than needed to be said, but there you have it nonetheless.