When you mention "even in our tests, this translates into more than 90 compilation errors" that's not comparing to 5.6 codebase right? Or are we potentially breaking code of pre-generic Query usage as well?

We are potentially breaking code of pre-generic FullTextQuery usage as well.

The reason is simple: before 5.7, FullTextQuery wasn't generic, so we could write this kind of code:

List<Foo> result = fullTextSession.createFullTextQuery( luceneQuery ).list();

We'd get a warning ("unchecked cast to..."), but since List is convertible to List<Foo> automatically, this would compile just fine.
In 5.7.0.CR1 (and earlier) we simply changed FullTextQuery to make it generic (FullTextQuery<T>, and changed FullTextQuery.list() so that it returned a List<T>. But createFullTextQuery still returned a non-parameterized (raw) FullTextQuery, and users only manipulated raw FullTextQuery}}s in their code, so this was mostly a non-breaking change ({{FullTextQuery.list would still return a
But if we make createFullTextQuery return a FullTextQuery<?> or FullTextQuery<Object>, now we have a problem, because the returned result of type List<?> or List<Object cannot be converted to List<Foo>.

I see no big value in adding a createTypedFullTextQuery at this stage; we can consider such things for 5.8 .. but as you say, it might be short-lived, unless we want to already flesh out the "right one", which will then become the only one in 6+. That would be ideal, and somewhat help the users eventually migrate to 6.

Yeah, the ideal would be to get it right immediately, but if we want to make these methods return query builders as we discussed last week, it isn't possible. It's simply too much change.
So, yes, let's keep it simple for now.