Which media directory?

That's definitely a bug I didn't notice, so I'll get that to fix itself, since the only check required for the public directory is to check that something is not already there either as a file, or as an unwriteable directory.

Re: The files

Actually you have two different versions, first is the original file, stored outside the webserver location, and the second is a "generic" derivative, which by default should shrink it to parameters which the webmaster can set. The original is kept, so that transformations can take place on it, without destroying the original.

These transformations already exist, but are done slightly differently that in the pictures module.

They can be found under admin/settings/media/derivatives. The idea here, is that different types of derivatives can take place for different kinds of extensions, and there can be "sub-derivatives" which are generated from not the original, but the derivative. These can be either public or private, which provides a rather powerful method to creating different kinds of media transformation systems. It's not quite fully tested, but you can add transformations to these derivatives such as crop, resize and scale already. I plan to add a heap more once we get some of the basic testing really out of the way.

Re: the filing system.

I didn't have any particular idea of where I would default the out of webserver access storage directory, since there are so many places these could be located. I tried to make clear in the description for it that it has to be an absolute directory.

The media_item_load(mid) provides the details as seperated things, such that the path you have is simply the path without the filename, makes it easier to handle name changes, and sorting by names...
If you put the $media->path together with $media->name you should get the full path (of where the ORIGINAL is stored). You can look in the {media_generated} table, and this would give you the location of the derivative (since the idea here is to be able to eventually, have something like a JS cropper intercede between derivatives to provide user selected areas. I really need to write more of this in the README files, since a lot of this is going to be necessary for people to understand how the system functions.

I've tried to keep it fairly basic when it comes to the design, but as powerful as I can get, while trying to keep all the possibilities in my head (not an easy thing to do).

This should be fixed in the CVS, including the concept of ../media, which functions also. This could lead to problems if people are not aware, so hopefully that will also get caught by the hook_requirements check.

Made the check for the public directory as whether there exists something there that could possibly stop it from functioning to either create the directory automatically, or to stop it from being writeable by the webserver.

If this doesn't function, simply change the status. :)

Oh and on the embed media, there wasn't any particular design, except to allow it to attach itself to ALL textareas, so I guess in a sense it was by design. I guess I may have to do something about that later.