Just as the rough estimate anyone can make by counting powers of $h$ in the numerator and denominator predicts, the Mathematica function Limit[f[h], h -> ∞] gives $1$ in the nonsimplified case and gives $0$ in the simplified case.

Now, I am a little confused about whether the correct limit is $1$ or $0$ ? And is the function Limit supposed to work that way as to not being able to distinguish the correct result from the wrong one ?

as you know, you can add or remove the //FullSimplify at the end of the definition for $a$ to switch between the two cases.

UPDATE:

As mentioned in the comments below, I have reported this as a bug to Wolfram support. They wrote back, were very polite and thankful, mentioned that this issue has been forwarded to their developer team and recommended to use Assumptions in order to be sure that everything goes well and additionally even speed up the computation.

@Artes: OK, I will report this as a bug.
–
KagaratschJan 22 '13 at 14:08

Just to make sure - I am right in believing that 0 is the right answer, aren't I?
–
KagaratschJan 22 '13 at 14:09

In Mma 8.0.1 (Mac) both expressions give a limit of 1. Also looking at the series expansion Series[a, {h, \[Infinity], 6}] it looks like 1 is the more reasonable answer.
–
Thies HeideckeJan 22 '13 at 14:09

@Kagaratsch Since the WRI people say they are aware of it, they'll say it is not a bug. Nevertheless one might expect a warning that some inconsitencies would appear. Since there is no warning one can encounter serious troubles. However Simplify and FullSimplify work well if one uses assumptions therein or in Limit.
–
ArtesJan 22 '13 at 17:20

We see if c is +/-I (if k is +/-1), the fraction is 0, so the limit is 1/2. If k > 1 or k < -1, then the limit of the fraction is -1/2, so the limit of a0 is 0. And if -1 < k < 1, then the limit of the fraction is +1/2, so the limit of a0 is 1. If c is real, then up above one can see the limit of the fraction is 1/2, so the limit of a0 is 1.

EDIT - Addendum

Prompted to investigate further by various comments, I have something to add, including what the actual limit for a generic complex $c$ is (which one might expect Mathematica could return as the correct answer). This goes beyond the current version of the OP's question, which stipulates that $c$ be real, but I hope it sheds some light on the issues Limit has dealing with this function.

Here is a plot of the real part of a0 vs. c when h = 100. The imaginary parts are nearly zero, and the real part is nearly equal to the limit. You can see the discontinuity forming along the red cliff. The limits at six test values are shown by the green spheres. We will use these test values for c again later.

I came up with ways to arrive algebraicallly at the different answers for the limits of a0 and a2 for a generic c. I doubt this is how Mathematica arrives at its answers, but it shows how the mistake might arise.

To find a limit at infinity, we can replace h by 1/k and let k approach 0. In calculus we learn to simplify the expression until we can plug in k = 0.

Conclusion

Whatever definite value I set c to, I always got the correct limit, but Limit does not handle c as a symbol correctly. With some careless algebraic operations, I was able to derive the answers Limit gave for original function and the FullSimplified version. Even with Assumptions that yield a unique limit, Limit does not always give the right answer. I would be surprised if it were mathematically impossible to develop an algorithm for finding a large class of limits including the OP's, given what can be done for integrals and by standard calculus techniques. I've never found a lot of use for Limit, but perhaps it is because of its limitations.

I was composing my response and so missed yours until after I posted. What I had to say is pretty much what you said (use assumptions).
–
Daniel LichtblauJan 22 '13 at 15:35

@DanielLichtblau I'm not surprised that assumptions affect the limits but I'd call it a bug that we have different values of limits with Simplify and FullSimplify.
–
ArtesJan 22 '13 at 16:07

@Artes No, these discrepancies all follow from the same underlying weaknesses in handling of radicals. The discrepancies themselves are not bugs because the Simplify/FullSimplify rewritings are not incorrect.
–
Daniel LichtblauJan 22 '13 at 16:12

@DanielLichtblau Nonetheless I'm not pleased with this issue. I would expect a warning that one should make assumptions on the variables rather than simply different values from limits. Moreover you can see that Limit[Simplify[...],h->Infinity] yields different results in M8 than in M7 and M9.
–
ArtesJan 22 '13 at 16:18

1

@Kagaratsch They're pretty much equivalent. With Block you can temporarily reset global variables. $Assumptions is used by many functions, including Limit. All or most such functions provide an Assumptions option to do the same thing. Using the option seems easier here, but I've got used to using $Assumptions inside a Block when testing things. You can cut and paste things into it, and my assumptions are up front and not buried in the options. You can use Block to wrap several commands that all have the same assumptions, for instance.
–
Michael E2Jan 22 '13 at 19:24

That is to say, while the original result was what the poster wanted, it is only by accident of haw some symbolic radicals were handled. Here is why it is not fully correct: for "many" values of c the limit is not 1.

Limit[{a, a2} /. c -> 2 I, h -> Infinity]
(* Out[81]= {0, 0} *)

Indeed, there is an interplay between real and imaginary parts that determines the limiting behavior.

All versions (7, 8, 9) return the same expressions respectively for a1, a2 and a3.

There is a serious problem in Limit at least since the version 7 ( seems like WRI emploees are aware of it). The way we simplify the expressions shouldn't affect its limits. So there should be a warning on possible inconsistencies.

Thank you, I will report it. I accepted the answer of Fabian since he has fewer points than you and therefore would benifit more from it. Hope that is alright.
–
KagaratschJan 22 '13 at 14:36

2

@Kagaratsch it is recommended that you select the answer that actually helps you the most, or when you cannot decide the oldest answer.
–
Mr.Wizard♦Jan 22 '13 at 14:46

@Mr.Wizard: In this case both answers correctly identified the problem as bug, so I was undecided. However, the answer of Fabian came 3 minutes earlier, so I am glad to know that apparently I did the right thing.
–
KagaratschJan 22 '13 at 14:50

Mathematica is a registered trademark of Wolfram Research, Inc. While the mark is used herein with the limited permission of Wolfram Research, Stack Exchange and this site disclaim all affiliation therewith.