I think that if you are talking about “hard coded cases,” my needs would be something like:
I do think that the “end of” part of “end of next week” is really unnecessary since it is assumed that we are talking about the next seven days. Even the “next” would be over-complicating things since that type of language is very precise (sometimes it reads awkwardly with the < > operators.) Again, I do not know if you were planning to implement that, but since you included that in your save search example, I am just adding my two cents
If you want to follow the natural language approach, adding a "day(s)"option(s) to what I already mentioned would work. Of course, now you would be dealing with parsing how many “days|months|years” we want to look into.
That is why from a programming and logical sense, [d] | [w] | [m] | [y] + # is kind of natural. I mean, it took me a while to figure out that to request the day, I had to do “[d] today.” Now that I know, it makes sense; but before, I was breaking my head – and I do not consider myself mentally inflexible and I read quite a bit of the documentation available. Nobody comes up with “[d] today” in a “intuitive and natural” way just out of the blue. In the same way, I think that just including a quick line in the manual mentioning that the parameters are “[d] + #ofDays” would be as intuitive as the other option.