In Drupal, an Input Format is a chain of Input Filters.
The term Input Filter is quite accurate when it is describing Filters for security. It is rather important to filter out dangerous HTML code, such as XSS scripts, masquerading, overwhelming CSS, etc.. to protect a site from malicious content.
There are also other types of Input Filters, but these are not really filters at all, but rather, Converters or Renderers. They may take a different document language, such as Wiki, BBCode, Markdown, or just regular text with line breaks and render it as HTML.
While it may be somewhat appropriate for a user to choose their favorite document description language as their Input Format, the security Input Filters to be a choice is rather awkward and unnecessary, even for the privileged user.
For most users who are not coders, who are not sentimental about historic conventions of describing formatting in plain text emails (Markdown), or protecting malicious input in less intelligent systems (BBCode), a true WYSIWYG editor is a modern requirement.
We now have a WYSIWYG API project that is pursuing to abstract the many JavaScript editors available and integrating them into Drupal.
While currently the Input Formats are describing a loosely-related mixture of Filters and Converters, the WYSIWYG API brings yet another lose attribute, the Editor type tied to the Input Format.
Now, the end-user has to choose the document description language and have a WYSIWYG editor that goes with that, and have certain security filters, all-in-one as an Input Format choice.
First of all, the choice for a document description language to go with a "WYSIWYG" editor is an oxymoron. The Wysiwig editor's job is to hide the underlying language, and show the result. So why should a user have to choose some coding language for input? Most users will find this awkward and confusing, except maybe us developers, who might find it entertaining to see an esoteric syntax render.
Second, the Input Filters for security should not even be a choice. If a special user has permissions to use certain tags or PHP code, they should just be able to go ahead and use them, without having to change their Input Format. And, if they already used such privileged features, why would they switch down to a more restrictive Input Format choice and disable themselves?
Then there is the other much-discussed issue of how to visually attach the Input Formats UI to the editor area, so most users who are currently confused by this option can perhaps deal with it better.
I think the the Input Formats need to go away completely. They are cumbersome for the general user, difficult to manage for the administrator (redundant chain portions), and limited in their usefulness because they are monolithic and not inline-able (more on that).
The Input Filters, those for security and filtering, should be an administrator choice tied to permissions, independent of Converters or Renderers or Editors that the user may call upon as they need or prefer.
All the other Input "Filters" (or really converters and renderers), those for Mathematical Notation, Musical Notation, Media Presentation, Images, Code Syntax Highlighting, Pirate Talk, BBCode, etc should all become "Inlinable" content from the same master WYSWYIG editor..
Because, documents are hybrid data types. They are by design, to accommodate the flow of different document description languages, charts, graphs, pictures, audio snippets, screenshots, code snippets, surrounded by formatted text and layout.
When someone wants to write about an image, a video, a couple of sound bites or PHP code snippets, they should not have chose a single node type or an input format for the whole document, but rather be able freely mix and embed these different formats in one WYSIWYG editor!
This is what these Input Filters (that are converters) should become, inline converters. They should have an XML language that is recursive, able to contain further content as children if necessary. They can do their conversion on the server-drupal side, and ajax-relay the results back to the WYSIWYG editor for live preview. All their options (crop, autoplay..), the ability upload attachments to be inlined, even specialized sub-editors (php code.) should be available as dialogs from the WYSIWYG editor as plugin modules.