TL;DR is that there is no canonical method to derive "value", and it is up to the various applications to determine how it derives it within the constraints, using arbitrary formulas.
While luminance has a very strict definition and varies from RGB colour space to RGB colour space, rarely does bad software handle it properly. The Y in YCbCr also varies based on the coefficients used.
In photoshop the technique in a nutshell: You have 2 scenes with a
mask mixed together. Then you add over them a 50% gray layer with
luminosity. That way you will get a color map of all the colors you
have in the scene.
Photoshop's handling isn't a reference. This is because it is a display referred application and handles colour in a hacky kludgy manner based on the limitations of the display referred model. The formulas Photoshop uses are mostly strictly display referred and can not work in a scene referred environment such as Blender. To see the display referred formulas, you can research the Adobe PDF specification that outlines the various blend modes. Specifically, in a scene referred model, colour energy values extend from potentially zero to potentially infinity, subject to quantisation limits.
The notion of 50% grey varies from implementation to implementation based on the models used.
So I tried to do this in Blender and found out that we don't have "luminosity", so I am trying to look something that works a similar way.
To apply a colour to greyscale image, you'd have to reverse the average luminance to the colour you have chosen. This is a non-trivial problem in a scene referred application such as Blender because of the variables involved. For the record, the proper luminance weights for a REC.709 / sRGB based reference space are:
(0.2126 * R) + (0.7152 * G) + (0.0722 * B) = Average Luminance
This works for both display referred and scene referred values, and as of the most recent master branch of Blender, should be what the RGB to BW node delivers.