New version of Patch 0002 (documentation patch) attached.  Patch 0001
(code patch) is unchanged.

>> None of the above have been obsoleted.  Let me know if I should make
>> them all obsolete aliases instead.
>
> I think that an alias is fine.
> At least, it is the approach I am leaning to recently.

Okay, we can obsolete it later if deemed necessary.

>> I haven't added this.  I think it's better not to do this, since cycling
>> is expected to only involve hiding/showing buffer contents.  Generating
>> a preview might cause new external processes to be started.  I can add
>> it if you think we should.
>
> ~org-cycle-inline-images-display~ already invokes link previews.

While that's true, link previews don't start new OS processes right now.
They can for custom :preview types.

> You do not have to implement it though. It is slightly out of scope of
> this particular patchset.

Okay, let's leave it out. This patchset has become reasonably large
already.

>> Subject: [PATCH 2/2] Org: Document preview API for arbitrary link types
>> ...
>> ...
>> +  By default, only image links without a description are displayed.
>> +  You can force displaying previews for all supported links using a
>> +  numeric argument of ~1~ to toggle all previews in the active
>> +  region, the link at point or the current section.  A numeric prefix
>> +  argument of ~11~ will toggle previews in the whole buffer.
>
> It is slightly inaccurate I think.  Once new :preview handlers are added
> to non-image link types, the same rule about links with/without
> description will apply to non-image links. So, we may better explain C-1
> and C-11 arguments in more generic terms: "image links without
> description" -> "previews for links without description"

Fixed in the the documentation patch.

I have one more question for you:

The overlay property that is used to check if it corresponds to a link
preview is inconsistent with the rest of Org right now.  We are checking
for the non-nil overlay property `org-image-overlay'.

1.  Should we rename this property to `org-link-preview-overlay', or
`org-link-preview'?

2.  Org's LaTeX previews (both the existing and WIP versions) use a
different system.  They set two overlay properties: `category' set to
`org', and `org-overlay-type', set to `org-latex-preview'.  Should we
use a consistent set of properties to identify Org-related overlays?

This is an implementation detail and none of it really matters, but I
can unify them if required.

If this is not an issue and there's nothing else, I think we are good to
merge.

Karthik