respect mediawiki-style image tags like [[Image:File.jpg|Text]]

Sorting input filters to avoid that kind of syntax clobbering is part of core. Set your flexifilter to a lower weight than Freelinking, and it should produce the HTML syntax before Freelinking can get it's hands on it. This half of your query is Fixed.

This kind of feature will not be added to the 2.x line without a patch.
FL3 will have a file handling plugin.

Currently working on [[file:filename.txt]] and [[image:imagename.jpg]]. Any modules worth mining for file data, please post here! I intend to look at getID3() and anything EXIF related once I have the basics put together.

Any modules worth mining for file data, please post here!

So, what about imagefield?
If a content type has exactly one imagefield, and that imagefield is marked as "use for freelinking", then [[Image:Node title]] should embed the image stored with the respective node.

Maybe this can be done with display suite, and custom node displays?
[[Node title]] would place a link, [[Image:Node title]] would embed the node as an image, [[Teaser:Node title]] would embed the teaser..
("Teaser:" and "Image:" would be plugins that are associated with display suite build modes)

Another issue is node title disambiguation / namespaces.
In Mediawiki, there can be independent articles "Amsterdam" and "Template:Amsterdam" and "Image:Amsterdam" and "Category:Amsterdam", without any name clashes.

The freelinking counterpart could be content type disambiguation. "Team:Gardening" would link to a node of type "team", while "Gardening" would link to a wiki page with the same name. Looks useful, but can conflict with other plugins.

Alternatively this could be done with taxonomy.

The ambitious goal is to allow easy migration between Drupal and MediaWiki.

Some grace in transitioning from Mediawiki is part of the goal of Freelinking, however it's not the entire goal. The next version of Freelinking is based on plugins, and you can build specialized plugins for any type of linking--internal or external.

3.x-alpha4 will allow you to pass the type as an argument to the nodetitle plugin like so:
[[Title|type=wiki]]

The easier syntax you describe could be provided by a custom module that invokes the nodetitle plugin. Documentation on that will come along once FL3 is more stable.

The Imagefield integration sounds interesting, but complex enough that I will leave that to a separate project. Freelinking 3 is thoroughly extensible and has a good API, it would not be difficult. My intention is to make use of the path to the file more explicitly, and recommend site builders make good use of Filefield Paths to build a good directory tree that incorporates node information.

I already have experimental code on the teaser idea, but for now the InsertNode module has that functionality. I have not decided where such a function should live, as it is definitely outside the core scope of Freelinking.

The simplest way to handle this is probably to have an option in Freelinking to leave content unchanged if the plugin indicator is not recognized by Freelinking. Then it will pass through and can be handled by another filter (like Flexifilter).

The solution described in #5 has been implemented in the latest dev snapshot of the 7.x-3.x branch.

There is now a checkbox on the settings page: "Ignore unknown plugin indicators". Ticking this will make markup such as [[Image:File.jpg|Text]] pass through Freelinking unaltered, provided there is no Freelinking plugin that uses "Image" as its indicator.

This should permit another filter to process it.

Please review.

This should be fixed in version 7.x-3.4.
Please see the release notes.