Versions are stored as text, not number.
This is the only way to support also version numbering like
1.2.3 or Beta 1.1 or whatever convention is used.

You could name your versions like 0.02 , 0.03, ... 0.10 to get what you want

That's fine, that's what PHP's natsort is for:
http://us2.php.net/natsort

AFAIK natsort can not be used for ordering in database. IMO sorting after database fetch should not be used because this would lead to performance / memory problems.

Ok. How about sorting the version based on the release date the same way they're shown for the target version?

Ordering by something which you don't see is confusing.

Introducing a new column "target_version_date" could avoid this.
But there can be no clean solution for this, because target version is stored as character in mantis_bug_table and not as a key to mantis_project_version_table.

The assumption is the developers will organize the releases based on the order of release, hence sorting by date should be a sensible workaround. Also, a simple join can solve the multiple table issue and if necessary, a compound key can be added to mantis_project_version_table for date, version so as to speed up queries.