$x in your example is not the part id, it is the offset count of that particular part. This differs from the part id in that, the part id is a unique string that identifies where the part resides in the MIME message structure, and the offset count is nothing more than the counter, which is used so that one parameter isn't overwritten by another. So distinguishing the difference is important.
As to your question, the filename isn't gauranteed to be set for any message part, neither is the CID. The ftype, (really the MIME type, not aptly named) is always set, and so is the file size. The filename of a part is even more unlikely to be set for inline message parts, since these are part of the message and not attachments. Because they play a different role this parameter isn't always available.
There was a bug in Mail_IMAP::getRelatedParts that was addressed in Mail_IMAP 2 alpha 1 RC 5. If you're still having problems with this, follow the bug submission guidelines posted on my website at http://www.smilingsouls.net
Given the plethora of different message composers and the potentially limitless possibility for inconsistency it's best to assume as little as possible about what parameters a message will contain. Bugs in Mail_IMAP are another possibility, this can be ruled out by outputting the object returned by imap_fetchstructure with var_dump and checking whether the filename parameter appears there, if it does then it could be a bug in my software, if it does not then the parameter isn't available. A Mail_IMAP_Debug class is included with Mail_IMAP 2 for this very purpose.
A PHP/C-Client/PEAR solution for webmail