Does MongoDB use indexes after root replacement?

I use following aggregation pipline:

db.myCollection.aggregate([
    {
        "$match": {
            "x": {
                "$lte": 100
            }
        }
    }, {
        "$sort": {
            "x": -1
        }
    }, {
        "$group": {
            "_id": {
                "y": "$y",
                "z": "$z"
            },
            "r": {
                "$first": "$$CURRENT"
            }
        }
    }, {
        "$replaceRoot": {
            "newRoot": "$r"
        }
    }, {
        "$match": {
            "a": true,
            "b": "value"
        }
    }
]);

Obviously, it's possible to improve performance of the query by adding following index:

db.myCollection.createIndex({ x: -1 });

The documentation says the $group stage will not use indexes, because it groups by another field then $match and $sort stages. Am I right, or is it possible to add x and y fields to the first index to use one?

And, please, help me to understand: can the MongoDB use indexes after $replaceRoot stage? Will it improve performance if I add the following index?

db.myCollection.createIndex({ a: 1, b: 1 });

You've asked two different questions here. This answer will focus mostly on the question in the title which is about index usage in a $match stage that follows a $replaceRoot.

The answer to that question is: no, an index cannot help here in your particular case.

Keep in mind that indexes are used to efficiently find documents in the collection. But after the $group stage here (and therefore the $replaceRoot as well) you no longer have the original documents. Instead you have synthesized something new. The database is going to operate on those new items after that point, therefore there would generally be no benefit (or even ability) to go back to the collection to begin scanning source documents once again.

There is potentially a special case when the $match predicates are on fields used during the grouping. However that does not apply in this case either. You confirmed in the comments that you cannot manually pull the trailing $match stage earlier as it would break the business logic. This is the same reason that the database would be unable to do so as it is not allowed to perform any optimization that would logically change the results requested by the client.

As for you other question about index usage for $group itself, last I checked the optimization you linked was not applicable for grouping on compound values as you have in your example. You could try creating a compound index on all three fields ({ x: 1, y: 1, z: 1 }) and see if the .explain() output shows a plan with a DISTINCT_SCAN on the version that you are using. Even if so it might not necessarily be faster depending on how many unique values there are for y and z.