Way back at the beginning of time, we (the PowerShell team) decided not to include interfaces in the list of types reported in TypeNames for a PSObject. I don't remember why we did this and can think of no good reason not to include them now. There are significant benefits if we do include them as end-users will then be able to write Type/Format extensions against interfaces e.g. write a ScriptMethod that works against IEnumerable. In particular this facillitates LINQ-like behaviours where a method can operate against an enumerable to return a new enumerable (lazy evaluation and infinite sequences). The one slight downside I can think of is that this increases the number of items in Typenames with may have a small effect on remoting due to transmitting the extra typename strings but we only do that once per object per operation so the impact appears to be negligible (at least based on my tests). There may also be a small increase in the about of memory used by objects but that's easily mitigated by unifying the type strings.

Implementation-wise, the Interface type names would appear after the concrete typenames so any existing type extensions will continue to work unchanged (i.e. not a breaking change.)

If you can think of any reasons why we shouldn't do this, please add comments to this issue.

Environment data

PSCore (1:90) >  $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0-preview.2
PSEdition                      Core
GitCommitId                    v6.1.0-preview.2
OS                             Microsoft Windows 10.0.17134
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0