Networking the PI through Windows isn't a primary goal of this project -- but not having network access (or even worse, having it intermittently) makes setting things up much, much harder. On top of that, a flaky network setup messes with Windows' cloud sync -- making some apps unresponsive, lock up, and possibly lose changes (bad if you're trying to take notes).

The problem(s) appears to be mismatches between the linux dhclient and DHCP server in Windows Internet Connection Sharing (ICS), and a flaky RNDIS driver/implementation.
This could be avoided in various ways, but ICS seems like a nice, simple way to go (if it worked better).

The workaround version is:

First boot: Wait at least 2-4 minutes for the PI to give up on dhcp and assume a link-local 169.254 address
Repeat: down-up the interface / disconnect usb / reboot -- until dhcp succeds
(it may succeed the 2nd time due to starting from the link local address & netmask?)
(but may still take a couple minutes after the login prompt appears)
Later boots: will probably still be slow because dhcp is intermittent, but it may fall back to the last saved dhcp reservation settings (if the address is not in use).

More Details below:

---------- more ---------

PreReq:

Setup usb gadget /boot/cmdline.txt :: dwc2,g_ether g_ether.host_addr=xx:xx... g_ether.dev_addr=xx:xx...
Change device driver to RNDIS
Setup ICS

First: how to spot part of the problem in windows

Open "View Network Connections" (typing in the start menu to search seems most consistent).
Windows may disable the RPI network device driver: re-enabling will fail, networking will not work. Then the RPI must be disconnected from USB and rebooted. (if it's not disconnected, or if you tried to re-enable it -- then windows may also require a reboot)

(the windows event log will show repeated 10400 NDIS "The network interface ... has begun restarting." -- "Reason: The network driver did not respond to an OID request in a timely fashion.")

Second: getting the right commands, to trigger a dhcp request

This first requires adding to /etc/network/interfaces
(otherwise you will get an error "ifdown: interface usb0 not configured")

allow-hotplug usb0
iface usb0 inet dhcp

Then, this command will restart dhcp on the interface

sudo ifdown usb0 && sudo ifup usb0

it will also show the output of dhclient. A typical result looks like this

DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 12
DHCPREQUEST on usb0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.137.1
DHCPREQUEST on usb0 to 255.255.255.255 port 67
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 13
DHCPDISCOVER on usb0 to 255.255.255.255 port 67 interval 19
DHCPREQUEST on usb0 to 255.255.255.255 port 67
DHCPOFFER from 192.168.137.1
DHCPREQUEST on usb0 to 255.255.255.255 port 67
DHCPACK from 192.168.137.1
bound to 192.168.137.118 -- renewal in 236 seconds.

Note: dhclient recieved two offers (from 137.1) but did not take the first one -- I've even seen it refuse 4 offers...
Unless it works immediatley -- there always seems to be 4 discovers before a request...
Where or how are the requests/offers lost or corrupted?
Future: there is a tool called dhcpdump that logs all dhcp traffic on an interface