I don't see anything wrong with what Trip.com are doing - buy the railcard now, possibly at a discount, and so you don't forget, and we'll actually deliver it, properly dated, once you buy a discounted ticket with it.
To be clear, what I was referring to isn't Trip.com's specific discounted railcard offers that require people to "activate" the Railcard by buying a ticket, but rather that there's a choice users are given when purchasing a railcard in the Trip.com app as to when the railcard's validity should start. (Attached screenshots to demonstrate this.) This functionality may or may not be to-spec at all, admittedly. By my amateur reading I would at least suppose it's staying true to the spirit of the "
speed of generation/fulfilment" specification that just seems intended to ensure there aren't unexpected delays for the user.
Regardless though, if Trip.com has a working implementation without issues then I'd personally say the rules should be changed to explicitly allow using this feature, or even encourage or require retailers to give the option using Trip.com's implementation, simply as a stopgap until the specification is further changed to provide a better solution. Obviously I recognise that changing the specification isn't at all in the power of any individual retailer.
(It does come across to me as if the specification is just meant to prevent actually issuing a railcard with the encoded 'start date' being a future date, so that retailers don't interface with the Railcard database in that way. Whereas Trip.com's implementation probably just delays issuing the Railcard at all until the 'validity start' date the users specify, the same way they delay issuing their 'special offer' railcards. Because ultimately, beyond this specific method of implementation not being foreseen, I can't see why the specification's writers would object to a retailer implementing this functionality?)