The link you provided, @sharpdrivetek, does not actually mention billed and shipped to addresses. Paragraphs 1(m) and 1(n) mention place of supply and delivery address (if different from place of supply).
I would interpret place of supply as your own address, already covered on Manager sales invoices. And I would interpret the customer’s address as delivery address unless a separate address is shown. Since, as you quoted my earlier statement, sales invoices don’t include the delivery address, you would have to add a custom field to sales invoices for delivery address (not shipped to address) for those situations where the normal billing address is not the delivery address.
Further, I see no rule actually requiring a delivery note or other document not satisfied by the sales invoice (relabelled as tax invoice). So I’m not seeing what you need that you don’t already have.
As for addresses appearing on delivery notes, if you’re using them and want a delivery address to appear, you need to enter the delivery address for the customer. It isn’t a bug that the billing address does not appear as the delivery address. It’s was the former design of the program and remains the current design after delivery addresses were added for customers. A bug would be something that produces a wrong result. In this case, there is no address because one has not been entered and the developer evidently decided not to substitute something else. You can enter any address you want manually, however. You might argue that the program should automatically substitute the billing address when no delivery address is provided, but that could cause problems. For example, a customer might have one billing address but always take deliveries somewhere else (such as construction project sites). So you wouldn’t want the billing address always being inserted on delivery notes.
If you read back through this entire thread, you will see that originally guessed that the implementation might include substitution of billing addresses for absent delivery addresses. My guess was wrong, and I agree with the current implementation. I had not fully considered all situations when I made my earlier guess.