That's the expected behavior, not a bug. Any parameter/property is NULL if not defined in a Registry object.

So, use:
$sets = $this->params->get('property_sets', new stdClass); or
$sets = $this->params->get('property_sets', array()); or
$sets = $this->params->get('property_sets', 'thing'); or
.... or ...
to set a default value for $sets for the next steps in your code.

Or use
if (!empty( $this->params->get('property_sets')) or
if (! is_null( $this->params->get('property_sets')) or
if (false === $this->params->get('property_sets', false)) or ... or ...

You're almost right. Take a look here: https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/installer/installer.php#L1555 - the installer parses the default values from plugin.xml and stores them in the database, so the default value should always be defined in the registry object. However, it doesn't handle the subform field properly, i.e. by parsing the formsource file and storing its default values.

Expected result
$sets contains one set with default values from propset.xml.

nope, NULL is expected result ?

same is true for simple text field

<field name="property_sets" type="text" default="ueueue"/>

$value = $this->params->get('property_sets');

$value will be null if the form was never saved before

you can have default value in next way:

$sets = $this->params->get('property_sets', array('foo' => 'bar') /*... default value ...*/);

or wait, I did not seen that installer.php#L1555 parse something,
then maybe try set default for subform field:

<field name="property_sets" type="subform" formsource="plugins/system/plugin/propset.xml" 
    default='[{field: "value"}, {field: "value2"} ... ]' ....

but I think installer.php#L1555 will parse it as simple string instead of json ?

well, just use default in your code:

$sets = $this->params->get('property_sets', array('foo' => 'bar'));

Closed as expected behaviour

Sure, putting escaped JSON in an XML attribute is such a good idea, next thing I need a custom build system to parse any referenced subform when packing in a simple plugin, and hardcode it inside a PHP script or an XML attribute. How about we fix the installer to properly handle nested fields instead of hacking our way around?

Oh and @brianteeman, maybe check GitHub once in a while and you'll notice @Fedik overlooked the parsing in installer.php, so reopen maybe?

fields instead of hacking our way around?

it not really haking, it how thing works

next thing I need a custom build system to parse any referenced subform when packing in a simple plugin, and hardcode it inside a PHP script or an XML attribute

well, I do not see any hardkoding in use Registry API to have the default value in your code

$params->get('key', $default);

it is easy

And I'm supposed to set the $default how? By parsing the subform each time the plugin runs? Let's face it, the way it's supposed to be is for the installer to parse the config when an extension is installed / updated and make sure the default (required) values are present in the registry. Currently it's not doing that when it comes to subform fields, and that should be fixed.

While I understand it can work by entering the same config multiple times, it's not something to be encouraged as it leads to inconsistency and hard-to-maintain code.