> I installed Ubuntu cosmic via the netboot ISO.

That explains, thanks.  The netboot ISO uses d-i, so will create this file at install time.

And I see that netcfg/finish-install.d/55netcfg-copy-config also has handling for
/etc/netplan/01-network-manager-all.yaml; so BOTH files are created with netcfg, which I don't think is the expected behavior.  At least, if we are creating a global file declaring that the network should be managed by NM, the generated /etc/netplan/01-netcfg.yaml should ALSO direct that the configured interface is managed by NM, NOT by networkd.

So with a VM installed using cosmic d-i mini ISO, I get:

# cat /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager
# cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: yes
# nmcli d
DEVICE  TYPE      STATE      CONNECTION
ens3    ethernet  connected  Wired connection 1
lo      loopback  unmanaged  --
$ networkctl list
WARNING: systemd-networkd is not running, output will be incomplete.

IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           n/a         unmanaged
  2 ens3             ether              n/a         unmanaged

2 links listed.
#

With netplan 0.40.2.2, if I rename /etc/netplan/01-netcfg.yaml to /etc/netplan/02-netcfg.yaml, now I see:

# mv /etc/netplan/01-netcfg.yaml /etc/netplan/02-netcfg.yaml
# netplan --debug apply
** (generate:2203): DEBUG: 13:13:12.964: Processing input file /etc/netplan/01-network-manager-all.yaml..
** (generate:2203): DEBUG: 13:13:12.964: starting new processing pass
** (generate:2203): DEBUG: 13:13:12.964: Processing input file /etc/netplan/02-netcfg.yaml..
** (generate:2203): DEBUG: 13:13:12.964: starting new processing pass
** (generate:2203): DEBUG: 13:13:12.964: ens3: setting default backend to 1
** (generate:2203): DEBUG: 13:13:12.964: Generating output files..
** (generate:2203): DEBUG: 13:13:12.964: NetworkManager: definition ens3 is not for us (backend 1)
(generate:2003): GLib-DEBUG: 13:13:12.964: posix_spawn avoided (fd close requested)
DEBUG: netplan generated networkd configuration exists, restarting networkd
DEBUG: no netplan generated NM configuration exists
DEBUG:ens3 not found in {}
DEBUG:Merged config:
network:
  bonds: {}
  bridges: {}
  ethernets:
    ens3:
      dhcp4: true
  vlans: {}
  wifis: {}

DEBUG:Skipping non-physical interface: lo
DEBUG:device ens3 operstate is up, not changing
DEBUG:{}
DEBUG:netplan triggering .link rules for lo
DEBUG:netplan triggering .link rules for ens3
# service NetworkManager restart # (done in order to force NM to see the config changes, since netplan did not restart it on netplan apply)
# nmcli d
DEVICE  TYPE      STATE      CONNECTION
ens3    ethernet  unmanaged  --
lo      loopback  unmanaged  --
$ networkctl list
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           n/a         unmanaged
  2 ens3             ether              routable    configured

2 links listed.
#

If I restore the original config (mv 02-netcfg.yaml 01-netcfg.yaml), reboot to clear the systemd-networkd state, then upgrade to netplan 0.96 from cosmic-proposed, I get the same state as when using 02-netcfg.yaml on netplan 0.40.2.2.

So there are a couple of things here.

- netcfg is definitely buggy, for the desktop install case; it is outputting instructions to netplan telling it both to use NM and to use networkd.  It should more clearly specify exactly what it wants the installed system to do.  I believe the intent is that NM is used for everything, when NM is installed; but in that case, either 01-netcfg.yaml should be cleaned up if it is not needed, or should be corrected to specify NM if the intent is to pass install-time configuration through to the installed system.
- it is documented that configuration settings in lexicographically-later files in /etc/netplan take precedence over earlier ones; however, netplan.io 0.96 appears to treat /etc/netplan/01-netcfg.yaml as taking precedence.  Perhaps this is because /etc/netplan/01-network-manager-all.yaml contains no device settings, only the global renderer selection.  In that case, I think it's not obvious that global settings would be excluded in this way from the normal precedence rules.