Sorry for the very wordy and technical title, hopefully the description helps show off this bug a bit better 
When typechecking the following code via both type solvers; the old type solver emits no lint warnings, while the new solver emits a type error, more specifically the following is the emitted analysis error:
Type Error: (9,1) None of the overloads for function that accept 1 arguments are compatible.
This appears to be due to the fact that, in the new solver, the inputted string argument is being interpreted as the more-broad āstringā type rather than itās singleton counterpart. This problem is somewhat common across the new type-solver, with type functions being another major case of this occurring; however in those cases it is much less obvious to the solver on whether weād want the singleton type, and weād presumably need a way to be able to tell the type solver that, in-order for those particular cases to be solved.
In this case though, the type solver should ideally be able to imply that Iād want the type to be interpreted as a singleton type; since the broad āstringā type doesnāt exist as an option in my intersection. The old solver did this, aswell as ānon-strict modeā in the new type-solver; and even autocomplete does this in the background (read below for more about that).
Sample code:
--!strict
type TYPE = (("string")->string)&
(("number")->number)
local FUNCTION: TYPE = newproxy()
FUNCTION("string") -- result should be of type 'string'
FUNCTION("number") -- result should be of type 'number'
Another really confusing part about this is that autocomplete is, in-fact, able to resolve the correct function definition to use. Not only are all the function arguments autocompleted properly but if you attempt to access methods on the āstringā function result, it will give you autocomplete results for the string class; whereas it will not for the ānumberā result (since the ānumberā type doesnāt have any methods). It does this even in strict mode. This further implies that this is perhaps either a bug or potentially an error that could become a disable-able lint warning instead.
It is worth noting that you can re-assign the type of the argument in order to remove the error; but this is a bit inconvenient:
FUNCTION("string"::"string") -- This works with no error
Also, it seems as if this has perhaps been already fixed in master branch luau but just hasnāt had the chance to be ported over to Roblox Studio yet: String literals aren't refined to singleton types in function overloads Ā· Issue #1589 Ā· luau-lang/luau Ā· GitHub; only noticed this near the end of writing this report and Iām not really sure about how the process for porting over the changes even works, so I still thought that making this bug-report may be best.
Expected behavior
Iād expect there to be no type error / warning produced in this case; or at least some way to retrieve the former functionality of there being no error. Iād ideally also like to use this structure of a type in a third-party module in the future, too. So in an ideal scenario, the solution would allow my own script to be able to disable the error, including for all other scripts which use my function. Although, I understand if that may not be possible given the current setup of the typechecking system and the way we currently disable lint warnings.
This behaviour change has unfortunately been a big roadblock for me since I wish to use the new type function system in order to generate these type-overloads (to produce what is essentially a basic form of a āmagic functionā; IE: a function with proper return types based on the inputted arguments). As such, I cannot use the old type solver as a workaround for this particular case; and I also donāt wish to have to turn off strict mode in my code-base as-so I can retain some of the other aspects of strict mode.