He hasn't made any real changes to the code so yes it appears to be the same.

More details here https://ixcoin.org/forum/index.php?topic=55.0

Correct. I did correct this in my subsequent post.

Well I'm no expert on the code, but MAX_MONEY is still set to 21000000 in main.h, so unless I'm missing something it's still capped at the same amount.

That issue has already been raised and discussed in this thread and the ixcoin developer has responded.

That constant does almost nothing. All it limits is the amount of money that can change hands in a single transaction, not the total amount of money in circulation.

That thread is incorrect in stating that blocks will begin being rejected. Things will continue past 21 million IXC as usual, unless one person happens to hold half of the money.

The point I was trying to make here is that Ixcoin's fundamental reason for existing (at least, the publicly stated one) isn't actually real, but it's still documented as such in the forum posting and the Ixcoin FAQ. What's wrong with re-raising the issue here? It seemed rather important to me.

You're right, there isn't a hard limit on the amount of bitcoins. 21 million is just rough level at which new Bitcoins generate per block is effectively negligible.

To make it clearer, this is what actually happens
1st "Stage": 50 BTC per block
2nd Stage : 25 BTC per block
3rd Stage : 12.5 BTC per block
4th Stage : 6.25 BTC per block
5th Stage : 3.125 BTC per block
6th Stage : 1.5625 BTC per block

So it just gets smaller and smaller so total Bitcoins would never reach the next million.

Your numbers are probably more accurate than mine since I'm basing mine based on reading wiki rather than delving into actual code
Doing a right shift sounds more sensible than dividing and getting fractions early as well.

Although I don't think it stops at 1, does Bitcoin count represent 1 BTC as an bigint 1 or actually 1000000 and simply putting the decimal for display purposes?

Actually I screwed up a bit here.  There is another line of code I forgot to take into account:

int64 nSubsidy = 50 * COIN

and COIN is set to 100000000

So it goes like this:

Stage 1 : 50
Stage 2 : 25
Stage 3:  12.5
Stage 3 : 6.25
Stage 4 : 3.125
Stage 5:  1.5625
Stage 6:  0.78125
Stage 7:  0.390625

and so on

I was just using 50 and shifting it, so you were actually closer to right than me, lol.  It will eventually reach zero but very slowly.  I guess I'm not exactly exploring new ground here, but we can at least say it is maybe more clear what is happening in the code, it just right shifts the subsidy every 210,000 blocks, and so yeah IXcoin would generate many more coins since it would be starting the right shift from 96 instead of 50.  That one line of code basically controls everything as far as new coins are concerned.  Does that matter?  Not sure in my opinion both overall counts are relatively low given that there are 6 billion+ people on the planet.  I know you can divide it out to 8 places, but who wants to do that?

Edit:  Also seems to be laziness on the part of the original developers of ixcoin that they didn't keep that consistent.  Bitcoin put MAX_MONEY in to check the size of a transaction, any transaction that tried to move more than 21000000 coins would fail since there aren't any more coins than that.  There will be almost twice as many coins in the new block chain, and the most they could still move is 21000000, admittedly a nice and rare problem for someone to have, but something they should've caught.  There is nothing in the code that would cause any other problems, you just wouldn't be able to spend more than 21mill all at once...

Holy crap, the price has crippled! I'm buying in! The more people that buy in the higher the price will rise