Image Content Type or Media File Type

One and the same web site may be in need of both of those alternatives, for various tasks and content arrangements.

IMO, we need the GUI to be flexible so we can arrange and re-arrange these content bits as we please, no matter which upload "method" was chosen in the first place.

A modern understanding of "CMS" indicates a system that lets us manage content dynamically, not set something fixed in stone so that it becomes less and less flexible to manage as time goes by and more content is added.

Therefore, I hope we can discuss how the GUI can be made so that we can have multimedia content take part in moderation and revisioning, plus handle multiple uploads elegantly as well. For the latter, I imagine that a multi-upload method can let us upload " to structure-1" initially, and then the GUI will let us shift some or all of the uploaded files to "structure-2" (or "the other structure") subsequently.

A multi-upload is meant to let us save time uploading, and that may involve such things as providing a zip file and have it automatically extracted to the server after the upload, and THEN present us with meta information fields for each of the extracted - say images; Title, description, tags, etc. One of the File Manager modules did this nicely already in Drupal 5. Then, on the page where we add this meta-info, we could also be offered to choose the storage structure method, either per group or per image or both.

However, that is only half the challenge. Here comes the bit that needs some extra pondering:

Should we need to choose storage method at all?

Would it be possible to create some sort of an abstraction layer between how the files are stored, and how they are used and presented, so that one and the same uploaded file could be used in both/all "ways" subsequently without affecting or changing where it is stored?

Ideally we could organize multimedia content into groups and/or hierarchies in the GUI as metadata, regardless of if all files actually is stored in a gigantic folder, in year-month-like folder structures, or on a per-user folder structure such as the IMCE module provides as an option. The ACL/Access control mechanisms should also take care of this transparently so we will be granted or denied access to each multimedia file irrespective of where each file is actually being stored in the file system on disk.

The shift towards Fieldable entities could perhaps provide the flexibility for this kind of abstraction.

Take a look at the Derivatives API. While the only working engine is currently the local FFMPEG for video/audio, @slashrsm's original GSoC project proposal included creating derivatives of documents. Document conversation was too ambitious for a single summer, but the API was designed with the hope that a JODConverter based engine would be added when someone had time to write that. Then you could upload a .docx and provider users a .ods, .rtf, or .pdf.

@StuartDH is asking about images. Why am I talking about video and docs?

As a community, we need to stop thinking of all files (text documents, spreadsheets, images, video) as anything more than a container for information that worked well with the desktop metaphor, but are now less relavant on the modern web. We should be thinking of files more like a Google doc or YouTube video. You upload "legacy" documents, but only save the information in a file container when you (or the service) are going offline. Similar to how the format and size of images are far less important because of the GD library, as FFMPEG and JODConverter become more common we will start viewing files as nothing more than a source document and generate derivatives as needed.

The questions about structure then have more to do with whether the derivatives are managed (media entities), unmanaged (image variations), stored locally, remotely (S3), or provided through a service (YouTube).

I work on a lot of community media related sites that deal mainly with video. In general we've been treating the node like the ID3 tag of an MP3... a place to store the metadata. Even though we can now add fields at the media entity level, it makes more sense for these sites to add that information to the node and relate it to the different derivatives of the media. This is what our ideal structure looks like...

Project (organic group)
- Show (content type with metadata)
-- Media (original - local)
-- Media (H.264 managed derivative - S3)
-- Media (Ogg managed derivative -S3)
-- Media (YouTube managed derivative)
-- Media (Archive.org managed derivative)

So for managed derivatives, I'd go with option #1. For unmanaged derivatives like images where the variations are not additional entities, option #2 becomes more appealing because it eliminates a level of hierarchy. If you have multiple managed derivatives (e.g. local original and Flickr) you can still use the Derivatives API to manage those relations.

Would it be possible to create some sort of an abstraction layer between how the files are stored, and how they are used and presented, so that one and the same uploaded file could be used in both/all "ways" subsequently without affecting or changing where it is stored?

We already have this abstraction layer in Media with PHP Stream Wrappers, though it's obvious are still confusing to many Drupalers. These wrappers can already be leveraged at the presentation layer to do exactly what you are describing. Watch @slashrsm's screencast on delivering HTML5 video using derivatives.

The ACL/Access control mechanisms should also take care of this transparently so we will be granted or denied access to each multimedia file irrespective of where each file is actually being stored in the file system on disk.

While files on a single server's file system may currently be the default for most Drupal sites, it shouldn't be the only configuration considered when discussing "file" management. We need to be working towards solutions that work "irrespective of where" the content exists on the internet.