[Bravo General] oldschool63:
Ok ... I'm answering my own question here, just in case someone else is interested in the solution:

General Information:

Historically (pc compatible) partitions used to be aligned on cylinder boundaries. Nowadays partitions are usually aligned on a sector number which is a multiple of 2048. For standard 512 sectors this evaluates to a 1 MByte boundary - which is also compatible with drives with a larger sector size (4096 bytes for drives > 2 TByte).

Logical volumes within the extended partition do not use the first head of the first cylinder (or the first 2048 sectors) because the area holds the volume's EBR - which is only a 512 byte record, similar to a MBR.

Implementation in the Motorola Bravo:

The Linux kernel reports 16 heads per cylinder and 16 tracks per head, resulting in 128 kByte per cylinder.

Partitions are aligned to this "virtual" disk geometry.

Digging through the list of EBRs (using dd and hexdump) I found that the partitioning utility used by Motorola creates volumes in the extended partition in a different (but still compatible) way: instead of wasting the first "track" (for the volume's EBR) in each volume, it consolidates all the EBRs in the disk space wasted by the partition entry for the extended partition itself (which usually is 1 cylinder or 2048 sectors).

Motorola actually allocated 512 kByte (1024 sectors) for the extended partition itself, giving the system the theoretical limit of 1024 volumes.

The question still unanswered though is: why does the extended partition (and the last volume in that partition) extend way beyond the end of mmcblk1?

Findings:

I searched around and I discovered that the tool Motorola used to create the partition table was most likely something like nand-part (part of the sunxi tools, please look it up on Wikipedia, I am not allowed yet to post links outside this forum).

This tool creates the EBRs for logical volumes in the same way as they appear in the Bravo's partitions. And most important, this tools also allows to create partitions which extend beyond the end of the device!

Ok ... on with the story: whenever a file system utility like mkfs wants to format a partition, it asks the kernel for information about that partition. The kernel is smart enough to correct partition definitions which extend beyond the end of device in order to avoid a failure or crash of the file system formatting utility. This "correction" is not permanent (partition table stays as it is) but done on the fly.

Conclusions:

nand-part's lack of parameter checking together with the kernel's smartness about partitions exceeding the device made it possible for Motorola to create one common partition layout for devices with different flash capacities: the setup used in the Bravo would be sufficient for flash up to 8 GByte without even changing the partition tables. The last partition (userdata) would simply benefit from a higher flash capacity.

Having answered that question, I still wanted to know what happenes when I try to correct that error (I know, I just asked for trouble). So I went ahead and as a first step I corrected the size in userdata's (mmcblk1p25) EBR to the correct value (using dd and a hex editor). After the correction everything looked fine. The definition of mmcblk1p25 now matched the actual size. I rebooted the phone and ... boom! The bootloader obviously was extremely unhappy and I was forced to do my first "sbf" - which I managed to do and meanwhile my Bravo is happily running CM10.2.

Dear Moderator:

If this post is of any use for the "Dev" section, please move it over there. I do not have the permission (yet) to post in the dev section.

Happy hacking,

Markus