No. The end of the booking window could just be extended by one day to {current date + 3 + length of ticket} each day at 7 am (with a max date of 14 days from the ticket start). So each day you'd be able to book one more day past the initial length of ticket days. This is similar to how FP+ worked for off-site guests - each day, the end of your booking window was extended by one day - the only difference is that under LL-MP the initial booking window would be # of ticket days instead of one day. There's plenty of evidence that G+ just modified the existing FP+ code, so it's not a stretch to think that LL-MP off-site booking could work similarly to FP+.
Again, you're making assumptions.
Off-property is length of ticket, but on-property is length of stay. So on-property guests can book non-consecutive days as long as they have a hotel booked for more nights than they have tickets. The scenario of the off-site guests who use their tickets non-consecutively is what developers would call an edge case (possibly even a corner case) and as such would be deemed not worth the effort and expense to accommodate.
The system has to set an end for the booking window. For on-property guests it's simple - check out date; but for off-property guests, the only real options would be a sliding window like FP+ based on the length of their ticket or a fixed 14 days from their ticket start date. They're not going to limit on-property guests to the length of their stay, but then give all off-site guests a wide-open 14 day window regardless of the length of their ticket.
I guarantee you that "length of ticket" was in the design requirements for off-site guest bookings, so if it were to be implemented the way you're speculating, someone would have had to ignore that design requirement to explicitly implement a fixed 14-day window for off site guests. However, testing would show that the end of the booking window and the max available date are always the same date in every scenario for off-site guests regardless of the length of the ticket and it would get flagged as an issue pretty quickly. If it actually gets implemented the way you think it will, several people messed up.
This is coming from nearly 30 years of development experience.