Currently there is no support for L2CAP connection oriented channels over BLE. It will be added a future version of the SDK.
Public and static random addresses are supported. If you program the chip with address FFFFFFFFFFFF the stack will generate a random address and will save it in the NVRAM, so the same address will be used forever after.
If you start scanning, you will see advertisements from other devices. See hci_client for an example how to do it.
By default there are 14 tx buffers. See speed_test for example.
hello_sensor uses .low_undirect_adv_interval = 1024 slots which is 640 msec. According to the spec the range is 20 ms to 10.24 sec.
I am not sure what you mean by lazy scan, but all scan parameters are configured in the blecen_cen_cfg structure. See hello_client for example. Similar to advertisements when application starts high duty scan (HIGH_SCAN), the stack will perform listen for high_scan_window every high_scan_interval and stay in that mode for high_scan_duration seconds. After that it will switch to low duty cycle mode for low_scan_duration. It is up to your application to specify how lazy it is.
No scan response is sent by the chip automatically according to the spec.
Application typically configures the scan/advertisements and chip executes according to the configuration. You can register to be called few milliseconds before the advertisement event to modify the data if needed, but this is it.
I do not know what cache you are talking about.
There is MTU exchange between connected devices at the time connection is established. 2073X typically supports default MTU of 23 bytes. There is a way around that though if it is required by your application, but implementation is a bit challenging. I suggest you develop your app with default MTU and if you hit performance barrier talk to us again.