When Mathworks constructs function names it ensures that if there is the same function name, that all except possibly one of them is a class method that is only invoked for specific datatypes, or that one is a name inside a +package that will only be used if called upon by fully qualified name or if import'd. Occasionally Mathworks replaces functions with other functions of the same name that do different things: in this case Mathworks builds in checks in the new one based upon number of arguments or data types and automatically calls an internal or renamed version of the older functionality. From time to time if Mathworks thinks that they are offering improved functionality, they might include a named option to invoke backwards compatibility.
So.. . the problem does not come up for Mathworks functions, other than potentially needing to invoke the same function name from inside a package or needing to invoke a superclass's version of a function (there is a syntax for that particular usage.)
This is not to say that the problem does not occur at all, just that Mathworks makes sure that it does not happen for their code. In the example you gave, passing a timeseries object to resample would invoke a name resolution process that would call the appropriate function that would not be called for passing doubles instead.
If you do happen to encounter the problem, such as if you are working with third-party programs that clash on naming, then one resolution is to cd to the directory that the shadowed function is in, take @ of the function, and cd back, and then use the function handle. @ function handles keep a record of the directory of the function the function was found in when the @ was built, and so can invoke the proper function afterwards.
