There's some discussion ongoing as to how to make this clearer, but I think the problem is that it's apparently difficult to understand the intended workflow of the new custom partitioning screen, because this is the source of the confusion. The description in the first post in this thread, for instance, is mostly wrong.
So here's how it's designed:
Down the left hand side of the screen is a display of all partitions - both existing and to-be-created - organized by the associated OS install [ 1 dans les copies d'écran ci-dessous ]
. It's not (as the OP thought) a display of 'potentially viable' partitions or something like that. It shows all your existing partitions (and non-partition storage devices - LVs, RAID devices etc), grouped by the OS install anaconda thinks they're a part of. So if you have a Windows 7 install and a Fedora 16 install on your system, on the left hand side, you'll see 'Windows 7' and 'Fedora 16' groups with the associated partitions inside the groups.
If anaconda can't determine that a partition is clearly associated with an existing OS install, it'll be displayed inside a catch-all 'Other' group. Post-beta, the dev name for these partitions ('sda1' etc) will be shown.
In the same list view on the left will be a group for the proposed Fedora 18 installation, just like the groups for the existing OS installs. [ 2 dans les copies d'écran ci-dessous ]
Any partition you create or re-map to be part of the proposed install will show up in this group (possibly after hitting the 'Apply' button). This group and only this group shows the partitions that will be created, re-formatted, etc as part of the install process.
The intended workflow is sort of backwards compared to the old way. Instead of looking at a diagrammatic representation of the disk, deciding 'hmm, I'll create a 2GB partition in that space and then do XX with it, maybe make it part of a RAID array' - the idea is that you decide what partitions your install will need - say, a /boot partition, a / partition, and a /home partition - create them, and then define their properties.
So when you create a partition you just get a very basic option: the mount point and size, that's it. So you create the /boot partition and set it to 500MB. *Now* you can define its properties, by selecting it and then poking the various buttons on the screen. You can decide what disk it goes on by clicking the 'gears' button. You can set various other properties in the right-hand side of the screen: should it be a basic 'raw' partition? Of type ext2, ext3, ext4, reiser...? Or perhaps it should be part of an LV? Or a RAID array? Or a btrfs group? Then you do the same for the / partition and the /home partition.
The approach is more functional than before. The old design was more sort of a graphical representation of parted, or something like that. The advantage of the new approach isn't that clear if you're just making ext4 partitions, but maybe it's clearer if, say, you want to use RAID. If you wanted to make / a RAID-1-backed partition before you had to create two partitions, make them RAID type, say you want to make them into a RAID-1 array, and then assign that partition as /. Now you just create a / partition of size (whatever you want), change its device type to 'RAID' and check the 'redundancy' checkbox. It's clearer and faster.
I don't want to sound too dismissive, but it's pretty easy to say 'I just want this' or 'I just want that'. Any _one_ use case is easy. If you sit down and think of all possible use cases of a partitioning tool with the flexibility of anaconda's, though, and try to come up with a really good design, it's incredibly hard. I think they've done a pretty good job with newUI for a first cut, though we clearly need to figure out a way to make the design more discoverable.
The old design was _familiar_, but it wasn't magically great or anything. If we'd started with the newUI design and switched to the oldUI design, I guess you'd probably have complained just as much.
edit: on sizing, the dialog is fairly 'smart'. It'll DTRT if you put in '1TB', '1000GB', '1000000MB', etc etc etc. I think it assumes the 'B' too, so 'T', 'G', 'M', 'K' should all do what you'd expect. I don't know what unit it defaults to if you specify no unit at all, but I'd guess MB. Maybe we need some guide text for this or something.
Adam Williamson | awilliam AT redhat DOT com
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora