There are several different things here that are perhaps confusing people.
1. How tickets are defined as being able to be fulfilled in the Retail Control Service (RCS) data
2. How TOCs have chosen to set up their flows (i.e. whether as eTicket, or m-ticket - or possibly both)
3. How retailers (both TOC and third party) have chosen to implement the fulfilment process
4. What retailers (both TOC and third party) actually call the different types of barcode ticket
1. Fulfilment methods
Retail Control Service (RCS) is an industry data feed used by TIS suppliers to determine how a ticket type (such as SDS) from an origin to a destination (e.g. YRK to KGX) for a given route code (e.g. 00000) can be fulfilled. There are numerous fulfilment types, such as ToD, smartcard, PTR (paper picket roll - sometimes referred to on here as "bog roll"), eTicket and m-ticket. From memory I think CCST is assumed, rather than explicitly stated. All TIS suppliers should use RCS, though one does not (though it makes no real difference to the outcome in this case as thy have their own version which is very similar). There is an explicit distinction between eTicket and m-ticket in this data.
2. Set up of flows in RCS data
For those flows that can be set up as in RCS data either eTicket or m-ticket, the following is a broad summary:
- SE, c2c and Merseyrail are not doing either eTickets or m-tickets on their flows, preferring smartcard fulfilment
- ScotRail are not doing either eTickets or m-tickets on their internal flows, but are supporting x-border flows that involve other TOCs
- Greater Anglia only added m-ticket fulfilment for their flows
- everyone else added eTicket fulfilment for their flows, though not all flows / products are yet enabled (and some can't be, e.g. where they cross London)
3. Implementation of eTickets / m-tickets on websites and apps
Different TOCs have implemented eTickets in different ways, even though there is a single RSP standard for this. This is clearly confusing people (unsurprisingly). The way an eTicket should be implemented I have explained in a previous post in this thread. I agree that it would be better if there was proper consistency (just as there is with CCST tickets (*almost!)). For how things should work, you are better off looking at a third party retailer (such as Trainline - I have no affiliation with them) and you will see that the method of getting eTickets is consistent across all TOCs. It's just that some TOCs (such as GWR and TPE) have done non-standard implementations.
4. Naming
Yes, it would definitely be better if retailers (whether TOC or third party) could follow naming convention. This should at least reduce customer confusion. The names probably need revisiting in any case, but that's different matter.