This is not a bug, but a consequence of the way order of operations work in pd. If an object has more than one connection coming from its outlet, it has to send data to one of them before the other one, so it sends them in the order that they were connected. In this case, the [f] object has two connections coming from its outlet, and the one going to the [+ 1] is the first one, so it sends data there first. But the [+ 1] object leads back into the [f] object, so another process is scheduled there, before it had time to send to the second [print] object. This happens 100 times, meaning that 100 [print] commands are waiting to be scheduled. When the feedback cycle finally ends (ie. the spigot is closed), they come out in reverse order because the -1 has been asked to wait 100 times, whereas 99 has only been asked to wait once.
To "fix" this, all you need to do it delete the connection between the [f] and the [+ 1] object, then create it again. The print command will now be received first and hence the numbers will come out in the right order. (It would be better to use a trigger of course--that's what it's for--except that it's sometimes tiresome to do all this rewiring, especially if you just want to do a quick print test).
This might seem like strange or artificial behaviour, but if it didn't work like this, chaos would ensue!