Prototype Design Pattern C++
Let's go through your questions.

No, it does not contradict the idea.
The base class should define the common functionality of the derived classes, that's needed by some system to operate on such objects. However, part of the code of that system, or a different part of the code base may be dedicated to working only with some of the derived classes, in which case the functions and variables should not be defined in the base class.
Using your example, a rendering system may require a Render() method and variables  defining the visual characteristics of a shape, which should be part of the colored shape interface. On the other hand, a system that works with shapes that have corners will not be expected to work on circles. In which case you would dynamic_cast a shape to the derived type in that system and call the methods specific to the derived class.

Depending on the debugger you're using, you are probably using a watch window to view the values of the circ variable. The watch window will display circ as a variable of type ColoredShapePrototype*, which only has a color variable.
In Visual studio, for example, watch window will allow you to cast the variable to a ColoredCirclePrototype*, by typing (ColoredCirclePrototype*)circ. You will then see the radius member of circ.

Smart pointers avoid common problems with managing dynamically allocated memory. unique_ptr specifically avoids leaks by deallocating the memory at the end of the scope, unless it is moved to another unique_ptr. If the clone() function returns a unique_ptr, this means the user of your prototype pattern code won't need to bother remembering to dealocate the memory. However, you are enforcing him to use a specific implementation of a smart pointer, in this case the standard library's unique_ptr. If this prototype pattern is part of a library and used in a project that has a different implementation of unique_ptr, it can become more complicated to manage this difference than if you return a plain raw pointer.

If a derived class has members that need to be deep copied, then that class needs to define a copy constructor that performs the deep copy.

My feedback



The most significant issue I see is that someone else can further derive a class from your derived classes, and there's nothing to remind them that the clone method needs to be overriden. Let's consider creating a ColoredSquarePrototype that inherits ColoredRectanglePrototype. If we create a square object and try to clone it, we would call the ColoredRectanglePrototype::clone() which copy constructs a rectangle, not a square. This is not easy to solve, one option is to declare your derived classes final, so they cannot be further derived. If you wish to allow derivations, you could read further about the issue in this blog post: https://katyscode.wordpress.com/2013/08/22/c-polymorphic-cloning-and-the-crtp-curiously-recurring-template-pattern/
I don't see the benefit of providing a default constructor in
ColoredShapePrototype, it just allows the usage of shapes with an
unitialized color (&quot;&quot;).
You should pass a const string&amp; to the constructors to avoid copying.
Removing &quot;Prototype&quot; from the name of the shape classes will convey better that these classes represent actual shapes instead of some auxiliary implementation.
The virtual void UpdateColor(int color) incorrectly takes an integer parameter instead of a string. This compiles, because the integer is converted to a char for std::string::operator=(const char) to be invoked.