Strange enough when I commit it has an end-of-line.

If this is just a useless temporary, creating it on stack will not need a free later on. Though I may be misunderstanding its use. I saw this because of construction using MEM_callocN instead of new.

This passing a temporary std::string to StringRef -> returning a StringRef -> creating a new std::string seems suspicious. Would the temporary outlive the function call, or would there be a dangling pointer ?

Also, std::string will count until \0 anyway, so using BLI_strnlen is duplicating the work..
https://godbolt.org/z/o3fW87

I'd say pass the layer->name directly to BKE_cryptomatte_extract_layer_name, get back a StringRef and pass it to other functions later on.

Just checking if a delete corresponding to this new is needed or if it's intentional to omit the destructor.

std::string has a constructor with const char * etc. A copy construction from another std::string is very likely not needed.
Same below. https://en.cppreference.com/w/cpp/string/basic_string/basic_string

Why mark return value const ? Anyone accessing the string through StringRef will not be able to modify the original string anyway.

Reference is not needed.. it's cheap to pass these around.

Same probably now applies to blender::StringRefNull key = blender::StringRefNull(propname);
Consider blender::StringRefNull key(propname);

Yes I missed these during cleanup.

Change to class, it does not compile using vc16.

To my understanding DNA char-arrays containing names are null terminated, except when they use the whole space. Therefore you always need to use BLI_strnlen otherwise it will construct an incorrect string.

I cleaned up the rendundant transformations.

I added some comments about the lifetime of the MetaData instance.

I kept to the C-function definition as it is a C callback. The constructor would not be called from C -> CPP as the caller is responsible for calling the constructor.

Oh, didn't know that.

Scratch this comment. It moved up because I had not refreshed while you changed the patch.
It referred to std::string key = std::string(propname); (which is now gone).

This .get() is not necessary. You can use the -> operator directly on the std::unique_ptr.

A bit redundant, but probably fine.

Don't use move in return, as it breaks return value optimization.

I think that this isn't the case here as the unique_ptr is owned by callback_data. When removing std::move here I get compiler errors. Perhaps you had a different approach in mind?

/home/jeroen/blender-git/blender/source/blender/compositor/operations/COM_RenderLayersProg.cpp: In member function ‘virtual std::unique_ptr<MetaData> RenderLayersProg::getMetaData() const’:
/home/jeroen/blender-git/blender/source/blender/compositor/operations/COM_RenderLayersProg.cpp:293:24: error: use of deleted function ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = MetaData; _Dp = std::default_delete<MetaData>]’
  293 |   return callback_data.meta_data;
      |                        ^~~~~~~~~
In file included from /usr/include/c++/9/memory:80,
                 from /home/jeroen/blender-git/blender/source/blender/blenlib/BLI_memory_utils.hh:26,
                 from /home/jeroen/blender-git/blender/source/blender/blenlib/BLI_array.hh:42,
                 from /home/jeroen/blender-git/blender/source/blender/blenlib/BLI_map.hh:72,
                 from /home/jeroen/blender-git/blender/source/blender/compositor/intern/COM_MetaData.h:23,
                 from /home/jeroen/blender-git/blender/source/blender/compositor/intern/COM_SocketReader.h:22,
                 from /home/jeroen/blender-git/blender/source/blender/compositor/intern/COM_MemoryBuffer.h:25,
                 from /home/jeroen/blender-git/blender/source/blender/compositor/intern/COM_NodeOperation.h:29,
                 from /home/jeroen/blender-git/blender/source/blender/compositor/operations/COM_RenderLayersProg.h:23,
                 from /home/jeroen/blender-git/blender/source/blender/compositor/operations/COM_RenderLayersProg.cpp:19:
/usr/include/c++/9/bits/unique_ptr.h:414:7: note: declared here
  414 |       unique_ptr(const unique_ptr&) = delete;
      |       ^~~~~~~~~~