HW errors are not correlated with accepted shares. Its an internal count that has nothing to do with accepted shares, only number that really matters is the %. HW errors on pool switches is a know bug with how bfgminer handles HW errors, not much you can do about it other than using the "Zero all stats" option under Display options until I find a fix.

1)Numbers look good
2)Download the new bfgminer version that addresses this issue
3)Your confusing the silicon labs UART driver with my bfgminer mining software(that includes the driver for the Moonlander). You don't need to reinstall the UART driver and do the workaround again, only thing you need is to just download the updated binary and run that instead of the old one.
4)Do you have a config.txt file that your running? This picks up settings as well, also make sure your not running off the desktop image when you download the driver, and save the bfgminer folder somewhere on your hard drive, otherwise changes you do to the start-moonlander file wont save.

My current bfgminer version is 5.4.2-38, sounds like you either compiled on my main branch(instead of the futurebit2-driver branch) or luke-jr's upstream repo? Just download my pre-compiled binaries.

Windows XP is nearing 2 decades old, and even Microsoft stopped supporting it years ago...you can't expect a new miner in 2017 to support it, I have no way of testing it even if I wanted to (which I don't...I hate windows ).

Like others have said, install Ubuntu on the old hardware, its one of the easiest to use linux distro's  (has a modern GUI). All you have to do is just download the linux binary after you install it and it should work out of the box.

No its 21 SHA256 shares which are 2^16 larger than scrypt shares. bfgminer was coded for bitcoin originally so this was never updated. I should probably update bfgminer's front end to differentiate between scrypt and SHA256 shares visual wise, but thats something for when I have spare time...which I have zero of these days :/

71m/27m is "milli" shares i.e. .0071/.0027 * 2^16 ~ 465/177 scrypt shares

New driver release is out, sorry for the delay and thanks for being patient. I added some last minute debugging code to better help people with issue and rule out any hardware problems. The compile binaries include the big restart fix, so these should technically hash forever without needing any manual restarts (as long as the power supply is semi-stable and you haven't really screwed up the voltages).

Let me know if the binaries run fine on respective systems...might have mis-compiled something while trying to keep track of every architecture 

https://github.com/jstefanop/bfgminer/releases/tag/bfgminer-5.4.2-futurebit2-beta2

Actually 706 is the network difficulty (which is 706 * 65k scrypt dif). Your pool diffs are 1 and 1m which is actually 64k diff (way too high for MLD2) and 1m which is diff 64 which is fine. Im assuming your having difficulties with pro-hashing, which has a default diff of 64k.

Quick update for you guys.

Batch 1 Stock has been sold out everywhere (including the in stock units distributors received separate from the pre-orders). Batch 2 Pre-orders are near sold out and will probably be officially closing it out this weekend.

Its also been brought to my attention that some of you are trying to get refunds from pre-orders due to LTC's recent price rise. Please keep in mind that all pre-orders are final. I don't do pre-orders because I want to collect all your LTC and profit. All my distributors, and especially myself operate on very slim margins, I don't have enough cash on hand to finance additional batches that require large sums of upfront cash for parts and ASIC purchases, hence the pre-order. 

All pre-order crypto funds are cashed out DAILY by my distributors to fund this endeavor, so there are absolutely no refunds, and are not even possible even if i wanted too since the bulk of those funds are in supply chain's banks already. Im sure most of you guys that sold your LTC in the 100's are not going to exchanges and asking for a refund, just like you wouldn't expect us to start asking more money for your pre-order if LTC price goes down 

PLEASE do not place a pre-order if your not comfortable with this, and wait until batch 2 in stock units to arrive (which will cost significantly more than pre-order units).

On the flip side a BIG THANKS to everyone that placed a Batch 2 pre-order and will allow an additional wave of moonlanders to spread around the world and decentralize LTC's blockchain!

Unfortunately these asics dont have on die temp sensors.

If your not running the stock setup I would really check the small heatsink temp with a heatgun before continuing to run them at max clocks. The heatsink is designed for induction flow with a fan blasting air on it in close proximity.

Overheated ASIC will NOT show excessive errors, either the buck controller will blow, or your going to burn out the ASIC. There is over-current and over-temp protection on the buck, so you will most likely kill your ASIC before you see anything wrong.

No I wish...just the source gets updated on commits. I have to manually compile and test for each platform on each release, which is why this is taking this long. I should be able to post all updated binaries tomorrow.

Try plugging them in all at once, then starting bfgminer with the default options. Then try lowering your frequency to the base 384 to rule out power issues. All your ports might be tied to the same power source on your motherboard (so it can't handle powering all at once)

Thats the only possibly for that error, look inside the bfgminer folder, you wont see bfgminer.exe in there. Your anti-virus is deleting it as soon as you unzip the folder.

Stock cooling solutions is good up to ~800 MHZ, after that you get into overheat territory (not to mention parabolic increase in current draw). The buck and ASIC can handle max frequency but I wouldn't run them unless you can measure temperature and its under 80C on the top of the small heatsink (translates to about 90C ASIC core). Anything past that your reducing the lifetime of the ASIC/buck. This will be even worse if you have a bunch of them together (since they are sucking each others hot air).

Check out the support thread linked in OP.

Any scrypt based coin.

Same deal as in linux, you need to specify the com port you want bfgminer to connect to instead of -S all (this searches for all moonlanders connected on the system) below is the format

Linux: -S /dev/ttyUSBn
Windows: -S \\.\COMn

where n is the COM port number moonlander is connected on (use device manager to find it).

Binaries for new Build will be posted soon, keep an eye on the releases page on my GitHub.

1 Accepted share is a share that is equal to or higher than the pool difficulty assigned to your miner. The device itself operates at a much lower hard fixed difficulty (scrypt difficulty 16 to be exact). Each red blink you see is actually a difficulty 16 share returned by the miner. This is needed in order to monitor the hardware and hash rates in near realtime.

 Hardware errors are based on on this driver level difficulty, so thats why even though you might only have 20 accepted shares at pool diff 512, you might have 100 hardware error shares, yet the HW error % is under 1%. Thats because the miner is returning an average 2-3 shares per second to the driver, but ~ 1 share a minute to the pool depending on pool diff.

I believe bfgminer --shares parameter uses the device level shares and not pool shares.

No, needs a complete reorganization, and separation of driver files etc. Its not as simple as changing the driver name. Configuration and make files etc need to be updated. Ill start work on that as soon as I have the moonlander 2 driver in a stable form.