Yes, HFXO is required. Also, note that it needs to be exactly 38.4 MHz. This is mentioned in the datasheet:

https://www.silabs.com/documents/public/data-sheets/efr32bg13-datasheet.pdf

See section 4.1.12.2 High-Frequency Crystal Oscillator (HFXO).

Check out this KB article, it has double-click detection implemented: 

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2016/12/12/bgm111_button_press-zsB1

The advertisements sent by the mesh example do NOT include device name. The examples that I listed above are from the soc-empty example that does not involve the mesh stack at all.

The settings you have defined in the GATT editor are effective when you start advertising so that the discoverable mode is other than "user data". For example, the soc-empty starts advertising by calling:

gecko_cmd_le_gap_start_advertising(0, le_gap_general_discoverable, le_gap_connectable_scannable);

Would it matter where I started storing the data, from the top or bottom, is there any real difference? Like starting from 0x4000 and going up or starting at 0x407F and going down.

No, it does not really matter. Those indexes are just used as "labels" for data. When you write data to PS area, the stack will any way fill it from bottom to top.

Do you know what happens when I start to go over the 2KB limit? Does it start to overwrite the last written value in that sector, newest written value, random, or depend on the PS key value?

If there's no more space available, you should expect some error message when you call ps_save. You can check it easily: write a test loop that writes some dummy values to PS until the stack throws an error code. If you write values that are 55 bytes long you can then estimate what is the max number of 55-byte keys you can store.

Alternatively do you think the switch to Mesh for NVM3 would be worth,

No, I would not recommend that. My suggestion is to first test what is the capacity you can get with PS. If that is not enough, then roll up your own flash storage mechanism by reserving one or more sectors from flash for your own use. It is quite easy to implement.

Persistent Storage is poorly documented. It's a list of keys stored in flash and the list occupies one sector (2kB), meaning that this is the ultimate limit for your storage. There's an explanation somewhere in the forum archives, I'll try to find it for you.

If you want to maximize the capacity, you should try to bundle as many 5-byte values into each key. This is because each key stored in PS will have some overhead. By bundling multiple values into one key you minimize the overhead.

For example, assuming one key can hold 56 bytes (= 11  values, 5 bytes each). You could store your first 11 samples in key 0x4000, the next 11 samples in key 0x4001 etc.

How much data do you need to store at minimum? PS is tricky because the Silabs BLE stack uses it to store bonding data and other non-volatile info. Therefore it is not that easy to estimate how much space will be left for your application.

Here is a sample advertising packet content for the soc-empty example. First version is the unmodified example out of the box. In the second version, I have ticked the advertise service checkbox for Generic Access service.

before:
0201060e09456d707479204578616d706c65

after ticking the "advertise service" checkbox for 
Generic Access service (UUID 1800)
020106030300180e09456d707479204578616d706c65
      ^^^^^^^^

The default packet contains only two AD elements: the flags and device name "Empty Example". In the second sample there is also one extra AD element to advertise the service UUID 1800 (marked with ^^^^ above)

I don't think there is generally need to advertise the Generic Access service, because I think basically every BLE device does have that service implemented. If you are not able to access that service from an iOS device then the main reason for that must be the limitations in iOS BLE API, as I mentioned above.

Here is a sample advertising packet content for the soc-empty example. First version is the unmodified example out of the box. In the second version, I have ticked the advertise service checkbox for Generic Access service.

before:
0201060e09456d707479204578616d706c65

after ticking the "advertise service" checkbox for 
Generic Access service (UUID 1800)
020106030300180e09456d707479204578616d706c65
      ^^^^^^^^

The default packet contains only two AD elements: the flags and device name "Empty Example". In the second sample there is also one AD element to advertise the service UUID 1800.

I don't think there is generally need to advertise the Generic Access service, because I think basically every BLE device does have that service implemented. If you are not able to access that service from an iOS device then the main reason for that must be the limitations in iOS BLE API, as I mentioned above.

Here is a sample advertising packet content for the soc-empty example. First version is the unmodified example out of the box. In the second version, I have ticked the advertise service checkbox for Generic Access service.

before:
0201060e09456d707479204578616d706c65

after ticking the "advertise service" checkbox for 
Generic Access service (UUID 1800)
020106030300180e09456d707479204578616d706c65

The default packet contains only two AD elements: the flags and device name "Empty Example". In the second sample there is also one AD element to advertise the service UUID 1800.

I don't think there is generally need to advertise the Generic Access service, because I think basically every BLE device does have that service implemented. If you are not able to access that service from an iOS device then the main reason for that must be the limitations in iOS BLE API, as I mentioned above.

For some reason, Apple has decided to not expose the Generic Access service (UUID 0x1800) to application level. See for example this link:

https://github.com/don/cordova-plugin-ble-central/issues/260

Do you have an Android device available for testing? WIth an Android phone/tablet and some generic BLE app (such as the Blue Gecko app by Silicon Labs) you should be able to see the Generic Access service.

The mesh advertisements do not include device name. The content of those packets is filled by the mesh stack and they contain information such as unprovisioned device ID etc.

See following KB articles that are related to this topic:

• KBA_BT_0503: Advertising Sets Used by the Bluetooth Mesh Stack
• KBA_BT_0504: Adding custom advertising to the Bluetooth mesh examples

If you connect to the device with your phone, then the phone can get the device name by reading it from the GATT database. If you want to have the device name advertised then you need to start a new advertising set to do that, just like you have done.