Follow-up from #7434 and related to #7498.

Note that this is a longstanding, albeit undocumented, behavior, and changing it now may break existing scripts, so there are two possible resolutions:

• Conclude that changing this would break too many scripts and therefore make do with documenting the surprising / inconsistent behavior.

• Conclude that this is a Bucket 3 change and make the change nonetheless.

The current behavior - quietly returning nothing and signaling success in $? - deviates from the typical behavior of asking for specific entities with literal names, e.g., Get-Item NoSuch.

Steps to reproduce

Ask for nonexistent type data with a type name that doesn't include wildcard characters:

Get-TypeData NoSuchType

Expected behavior

A non-terminating error indicating that no such type data is loaded into the current session.
$? should indicate $False

The error message should be similar to the one for Get-FormatData (which is suboptimal as of this writing), which, modeled on my suggestion here, could be something like:

No extended type data for type name '{0}' has been loaded into the current session.
Note that type names must be specified exactly as defined and are typically full .NET type names.

Actual behavior

Nothing ([System.Management.Automation.Internal.AutomationNull]::Value) is output, and $? reflects $True.

While this behavior may make sense for wildcard-based arguments, it doesn't for literal ones.

Compare this to the behavior of cmdlets such as Get-Item, Get-ChildItem, Get-Content, ..., which all fail if a given non-wildcard path doesn't identify an existing file.

Environment data

PowerShell Core v6.1.0-preview.4 on macOS 10.13.6
PowerShell Core v6.1.0-preview.4 on Ubuntu 16.04.4 LTS
PowerShell Core v6.1.0-preview.4 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)
Windows PowerShell v5.1.17134.165 on Microsoft Windows 10 Pro (64-bit; Version 1803, OS Build: 17134.165)