Is your feature request related to a problem? Please describe.
Not related to a problem, but thinking about it as a nice addition. Some signalling systems in certain countries (or even between railways of the same country) add extra aspects to signals in order to issue additional meanings like:

• Advance at a (very) reduced speed
• Authorization granted to enter station for maneuver
• Commercial stop (stop briefly because there is passengers/cargo available , not traffic context where the next block is busy/is unsafe to proceed)

While those meanings could be achieved using extra semaphores, solution isn't as elegant because it could end making very big headed signal clusters that don't fit well with the scale of the rest of the railway, also each implementation is different and subject to interpretation - complicating the initial simple nature of the original signals.

Describe the solution you'd like
Make some additional signal aspects (colors?) available. Suggestions of colors:

• Blue (could be used to indicate slow speed)
• Purple (commercial stop)
• White (maneuvers)

Not sure about how they should be sorted in terms of restrictivity, I guess they would be more restrictive than green and less than red. An idea could be Red > White > Blue > Yellow > Purple > Green

Describe alternatives you've considered
As mentioned before, an alternative could be using combinations of current signals. The combination of colors and the disposition of the semaphores provide their meaning.

Additional context
Some photos of extra signal aspects to provide evidence:

• Purple, Blue and White lamps
• White aspect used in Italy
• UK shunting signal
• Australian signal
• White lamp used in Chile with red aspect to indicate maneuver
• Chilean white aspect
• Purple signal in the US
• White signal in the US
• Purple small signal in the US
• Blue signal in Germany

Hope this gets considered, thank you in advance.

Armando Rojas, in the very first message, there is a picture of a traffic light in Germany, which does not correspond to reality, since it is a shunting traffic light with a white with a blue signal from Russia (let's take this region of the Leningrad region, where the presence of contact network elements mounted on a horizontal console with a suspension on a rigid straight UKS unification insulator is characteristic).
I will add that in Russia and the CIS countries there are the following signals:

1. Blue - It is forbidden to perform maneuvering work (for example, movement under a train or to any other section of a busy or free track, but when receiving, departing and moving from one station park to another according to indications such as green or yellow lights, the driver ignores the blue traffic light.
2. White - allows maneuvering in the direction of an occupied or free path.
3. White flashing is a practically unused signal, since it is needed mostly in various emergency situations (for example, when it is necessary to receive/send a train to or from a station if it is impossible to open the station traffic light in a normal way); white flashing light can be used in conjunction with a constantly burning red light, as without it.

I will add that in Russia and the CIS countries there are the following signals:

That is right, but these signals are used manually. Can you describe when they could be shown?
Also, if I'm not mistake, no locomotive in Railcraft cares about signals. How you want to setup behaviour?

Without these answers any new signal aspect would be pure visual or range increment.

My implementation is aimed at organizing movement and control by several people, but after playing a little with various detectors, this system can be quickly adapted into a mode where locomotives can stop and start moving without a driver, and the traffic lights themselves will remain as an additional visual component that will add realism to the system...

I have already assembled a trial system, but the lack of necessary aspects broke my brain on the possible implementation of crutch methods. Now, due to the lack of necessary aspects, builders and those who can be attributed more to engineering cannot implement some systems that they are used to working with, for example, in real life.
For example: if a system is implemented on the server where there is a clear structure of drivers who are engaged in transporting something or and the structure of dispatchers who direct the movement of drivers, then they should have something in common in the form of understanding each other's actions, in particular, the driver approaching the station under certain conditions understands that the train arrives for example from speed limit or without it, on deviation or straight, on a busy path or free, the duty officer even without seeing the rolling stock, and seeing the conditional control panel should correctly direct the drivers to perform certain target assignments to perform a common task, but in fact, without some aspects, the implementation of generally accepted systems is a little lame.
In reality, I work as a train driver on the railway, and it is very difficult for me to do the wrong ways of management and control due to the lack of necessary aspects.
Here is my example of a neutered version with incomplete control of actions and functionality (where it is impossible to open a traffic light (that is, to give a command to a real player) to receive a station on a busy path), where there is protection (in the form of non-opening traffic lights on the way with another train).
https://www.youtube.com/watch?v=hLVR7LDtisQ&list=PL2mjdtD0nSu6_tW-0z2XWticqCiwNAS4K

if a system is implemented on the server where there is a clear structure of drivers who are engaged in transporting

So you suppose players to drive trains. That means signal aspect range increment.

but after playing a little with various detectors, this system can be quickly adapted into a mode where locomotives can stop and start moving without a driver,

I have serious doubt about it. There is no direct locomotive control by RS logic and RC tracks just activated or not. This makes changing of manoeuvres quite complicated.

I'm real life railways engineer btw (SCB). And I understand your desire to have "proper" signalisation.

While this is better thought out than most people's requests for more aspects, it still fails to answer a few fundamental questions.

Namely, how should the signal decide that such aspects should be displayed?

Thank you for answering. Good to see you back again.

Trying to answer your question, I'll explain more or less the intended purpose of each signal aspect and how/when could it be displayed:

• White aspect: In my country, the white aspect is used in addition to a red station entrance/exit signal. It means that your train should be entering/exiting the station in the context of a maneuver, so you should be doing it slowly. It does not grant entrance or exiting authorization the way a green/yellow signal does, as usually trains with this signal are trains that exited the station to the main line block in order to perform the maneuver, and then must return to the same station. You are not allowed to go to the next station when Red+White is present on a exit signal. Think about it as a "conditional" entering/exiting permit that temporarily overrides the red signal. Also it applies when the station track where the train is entering to is not being monitored (controlled by block signals), so no guarantee about the track state (ocuppied or not) can be given automatically by the system, then the driver should proceed with caution. Also, the aspect is used on its own for some special signals.

• Purple aspect: purple informs you about a commercial stop. Even if you have green on your exit signal (block is clear and you are safe to go), you should not go unless purple is off. A Block Signal, and its current aspects (R,Y,G) tells you about the safety of proceeding. The purple signal tells you "you can leave the station because the next block is clear (which could be informed via another Block Signal in green aspect), but you shouldn't because you are still loading/unloading cargo/passengers, or you cannot leave by schedule and should wait", and should be used indepently of the block state, like players could use Distant Signals now, or the current Blinking aspects via a Signal Controller Box. Trespassing a purple aspect should not affect the safety of the traffic, and only should be displayed, if using the same signal as the block state signal, if the next block is clear (that is, no Red/Yellow aspects).

• Blue aspect: This signal tells you you should reduce your speed to the maximum possible. Some use cases could be that is the last block, and you are near a Buffer Stop, be ready to stop, not because the next block is busy, there are just no more blocks ahead. Or you could be entering a loading/unloading track that requires you to pass slowly if not stopping your train completely. Also it could be used as a entrance signal for train storage tracks, and near coupling/decoupling tracks.

Now, how to automate these aspects?

There are two choices:

1. Let the aspects be set manually only, using a Signal Controller Box. In some scenarios, players tend to play and operate railways not 100% automatically, and in those cases these additional aspects could serve to relay additional information to the drivers. Then the players could customize the meaning of the aspects, offering more choices to them while reducing the implementation complexity at the same time, and solving the problem of using extra signals to provide additional meanings (which can be confusing with three aspects only, and should rely more on the position of the signals),, while still having a predefined restrictivity (or, the restricivity of these "custom" aspects could be configurable).

2. Try to automate them anyway:

• For the Blue Aspect: detect if the block has a Buffer Stop Track / there are no more blocks ahead. Then this aspect replaces Green or even Yellow on the entrance Block Signal. You can advance, but as slow as you can. Also you can use it when there are loaders/unloaders present on the block, but I think some players could find it annoying if we force this aspect on their setups.

• For the Purple Aspect: similar criteria of the former aspect, you can detect if the track has loaders/unloaders, while those blocks are performing operations, the exiting Block Signal that allows you to enter to the next block should show Purple instead of Green.

• For the White Aspect: this is a bit more complicated. Since the White Aspect is used in my country as a complement of a Red Signal, I'm not sure how to add it as a independent aspect. Maybe it could be implemented as a Test Signal Aspect. Authorization of entering a block that is potentially unsafe to do, or allowing to enter the main line with intention to return to the same station without going to another station/block first should be made manually. I don't know exactly if there automated rules about the usage of White Aspect in my country, I think it is a fully manual operated independent light.