How to index for a query with independent range conditions?
MySQL can do Index Intersection (more commonly know as Index Merging). However, in your case, I have something more reasonable to suggest.
You mentioned in a comment

X is a VARCHAR and Y is a DATE

For the sake of example, we'll use this query
SELECT A,B FROM mydb.mytable
WHERE X &lt; ? and Y &gt; ? ;

You need to create an index, but you must examine which order of columns forms the smaller range for a first column. Is it (X,Y) or (Y,X) ?
CHOOSING X (VARCHAR) FIRST : This means looking over at least 1296 (36 * 36) possible alphanumeric ranges. Then, within each character range, compare a range of dates up to today's date. 36 is 26 Alphabetic and 10 Numeric.
CHOOSING Y (DATE) FIRST : This means looking a range of dates up to today's date. Then, within each date, compare a range at least 1296 (36 * 36) possible alphanumeric ranges.
You can decide which by running these two queries:
SELECT COUNT(DISTINCT Y) DateCount FROM mydb.mytable WHERE Y &gt; ?
SELECT COUNT(DISTINCT LEFT(X,2)) CharCount FROM mydb.mytable WHERE X &lt; ?

Which combination forms the smaller set? This would be hard to judge if you have something lopsided like X &lt; 'Umbrella' or Y &gt; '1929-10-29'. These are ranges too unreasonable for a query optimizer to want to use an index.
If the date range is short, create an index with (Y,X)
If the string value range is short, create an index with (X,Y)
I would create both indexes and let the Query Optimizer make the decision. Yet, there is something else you can do. Look again at the sample query.
SELECT A,B FROM mydb.mytable
WHERE X &lt; ? and Y &gt; ? ;

You can boost performance by creating a covering index. That's an index that has all the needed data in the index which bypasses the need to read data from the table. In the case of the above query, you could create the two indexes like this:
ALTER TABLE mydb.mytable ADD INDEX idx1 (Y,X,A,B);
ALTER TABLE mydb.mytable ADD INDEX idx2 (X,Y,A,B);

With these two indexes, the Query Optimizer will do an index scan in the worst case scenario since all the needed data is already in the index and there is no need to get anything else from the table. This is very beneficial for both MyISAM and InnoDB.

MyISAM : only caches index pages into the key buffer
InnoDB : only index page are loaded into the InnoDB Buffer Pool
See my post What are the main differences between InnoDB and MyISAM?

As for Covering Indexes, I mentioned using them in past posts

Jan 01, 2013 : Performance impact of including result column in indexed columns
Nov 13, 2012 : Must an index cover all selected columns for it to be used for ORDER BY?
Oct 17, 2012 : Combining columns in index
Mar 12, 2012 : How to index this table (a_level, b_level, item_id)

SUMMARY
Dealing with independent ranges may make accurately forecasting which index combination is more relevant can be challenging. Furthermore, imagine the anxiety you will have as to how the  query optimizer will evaluate thing. In light of these, you will need to go with covering indexes as much as possible. You will have to also schedule a periodic run of ANALYZE TABLE mydb.mytable; if the table experiences heavy INSERTs, UPDATEs, and DELETEs.