When copying (From CS Manage "Modify => Copy with a different") and in the unfortunate the characterisation mode was "Gamut Sweep", that "Gamut Sweep" becomes "Profile" in the copied file (Figure 1).
This looks limited to the "Gamut Sweep" case. Tried with "Grey Ramp RGB" and with ".... Ramp+" cases and copying works fine. Don't take for granted as I could have missed something.
I have also attached a dump of the header of two files (Figure 2) that may help with the root cause.

Figure 1

Figure 2

Hey ebr9999.
Interesting one.
Can you reproduce it - as in does it happen every time you do the copy?
Would you mind posting the original profile here or send to Steve so we can take a look.

Thanks,
Mike.

Here the two bcs (the one with 75 is the copied one)
It happens for each copy I do starting from a "Gamut Sweep" Mode.
No issues if I display it and then save it. In that case the "Matched" info is lost, but that may be (hopefully) fixed in a future

Attached file: The two bcs

This is actually expected operation presently.
The different 'Profile Formats' are just in indications of the underlying profile, other that those that have specific functions.
Profiles, such as Gamut Sweeps are really sub-sets of volumetric profiles.
And when edited the link to the original profile data is lost, so the new profile is ladled as the parent Profile type.
This is not new in the Beta - it is how ColourSpace has always worked.

Steve

I am COPYING a profile, not editing (Have a look at the first message). A metadata is lost in such a case!
That's the only way I have in CS for RENAMING a profile.... By the way editing (i.e. in CS words "Displaying and saving", it works as I expect.
And it works as I expect for Gray Scale and ".... ramp+".

Sorry - as explained above this is presently expected operation of profiles that are a sub-set of a volumetric profile.
That means Gamut Sweeps, Memory Colours, but not Ramps and Edge profiles, as they are non-volumetric profiles.
Changing the name by using Modify is an edit of the profile in this situation.
This is the way ColourSpace has always worked, and is not something new in the Beta.
As such, it is not a bug in the Beta.

Steve

ebr9999
Thanks. As Steve says, we are quite careful not to modify existing profiles.
When you select "modify" and save under a different name, what happens is a new profile class is created and the data copied across from the one in the library and sanitized. Then it is saved on disk.
If it was a direct copy then it would be bit perfect. We'll take a look.
You can copy the file in the library if you wish as a workaround. It will be loaded automatically when the tool starts.
You should change the internal name to match the file name ideally, but the tool will now patch that if they are miss-matched.

It looks inconsistent to me that a differentiation you have introduced for built-in profiles (i.e. memory colours and gamuts sweep) is lost, if, for any reason, you have to change the profile name.
And that only because the "Analysis" metadata is not copied when doing something that corresponds to a save as. Never noted anything like that for the other metadata.
I acknowledge it has not been introduced by this open beta and I understand you are reluctant to consider it as a CS bug. Can you please change the title so that it becomes WIBNI?

Title changed.

Steve