i'd like to see more lighting in the game. like if you put a coloured stained glass in front to a redstone lamp the light changes to the colour of the glass. i think this could be interesting and could help map creators or builders to be more creative with lighting. comment if you agree
Using glass to change the apparent color of the light emitter can be done now, it's just neither compact, nor particularly convenient.
Changing the color of the emitted light has technical issues and would likely be much more laggy
Colored lights (eg objects like Xmas lights) should be fairly simple to code whereas colored light (a phenomena) would be far more expensive in terms of performance. [If the light was colored, each block would (theoretically) need to be rendered to account for the interaction of the color/spectrum of any light source that reached it and the reflectance spectrum of the block qv. https://en.wikipedia.org/wiki/Reflectance . Breifly, a red object will appear black when illuminated by a light source that contains no (or very little) red. ]
This renders one face of a block; note the "setColorOpaque_F" calls, which set the R,G,B color components for each vertex - they are already calculated separately and all you'd need to do is have three light channels in the world data, each one only affecting each color (the actual color of light is currently set by a light table, so that sky light is white or bluish and block light is yellowish, which could both be used for "white" light, much as e.g. white stained clay is not pure white).
True, there would be some limitations, such as what happens if you had an orange light source (red = 15, green = 8); the color would change from orange to red with distance since green would reach 0 while red is still 7, plus the gamma curve is not linear, and varies with the "brightness" setting:
Light filtering can be implemented by simply extending the current light opacity system to have separate values for each color instead of one (so a block might be opaque to red light but let green and blue through). This would require 3 times the calculations when propagating light but I've optimized the lighting engine myself enough to more than offset that (in particular, the laggiest part is when the game relights chunks right after they are generated, which is done over several minutes by relighting a few blocks per chunk section per tick, which I made so much faster that I sped up the process by a factor of 8 and it still causes less lag. I didn't actually change the algorithm, just optimized calculations and loops and most importantly, directly access the raw block/light data from a chunk cache (this is one area where the internal changes to not use block IDs, even internally, and adding complicated "blockstate" and "blockpos" objects and other such wrappers hits 1.8+ very hard. I doubt that even with the claims of optimizations in e.g. 1.14 they could ever match the speed or memory footprint of older versions).
Here are some articles that discuss the same general lighting engine that Minecraft uses, including colored lighting (even a "fast" voxel lighting algorithm will still be relatively slow compared to other means due to the nature of how light is propagated, the alternative is dynamic shader-based lighting but that has its own issues, including the fact that many game mechanics depend on the light level):