ORDER BY ... LIMIT optimization issue (bug 12113?)

[Samuel Ziegler]

It seems that there is a case of ORDER BY ... LIMIT where the optimizer
isn't choosing the best plan.  Specifically, it is using a partial key
for the WHERE clause when it could be using more of the key to fulfill
the WHERE + ORDER BY.

An example SELECT statement would look like:
SELECT * FROM a WHERE key_part1 = 4444 AND key_part2 > 5555 ORDER BY
key_part2 LIMIT 400;

The symptom is that instead of key_len = key_part1 + key_part2, it is
just key_part1.

I believe this issue may be the cause of bug 12113, but I don't
understand the code enough to be sure:
http://bugs.mysql.com/bug.php?id=12113

It appears that the issue stems from this line of code in sql_select.cc:
(Line 602 in 5.0.33)
  row_limit= ((select_distinct || order || group_list) ? HA_POS_ERROR :
	      unit->select_limit_cnt);

Since the select statement has both an order and a limit, this line of
code is setting row_limit to inf.

Then, later, when the plan cost is being determined, it decides that a
row scan is warranted because the cost of walking the entire index
(since row_limit == inf) is greater than the cost of a complete table
scan.

Questions:
- Is this an accurate interpretation of the situation?
- Is there an SQL way to force MySQLs hand?  (I tried force index, but
that didn't seem to help)
- How would it be possible to modify this if statement, or the cost
estimation to take this optimization into account?

Thanks!
  - Sam