If AP0 are the primaries used for rendering, then colours outside the sRGB space will work fine (assuming the colours are still within the AP0 space of course). If you allow users to pick colours in AP0 and then render with sRGB primaries, you will either end up with invalid colours (outside the zero to one range) or gamut clipping.
Assuming AP0 is used internally for rendering, then whether or not there will be data loss depends on the pipeline.
If a user picks a floating point colour outside the sRGB space and it is converted and stored as an integer value in sRGB (for example a PNG texture of whatever), there will be a loss of colour gamut but very little loss of precision. If it is stored as a floating point texture in sRGB (such as OpenEXR), texture values outside the gamut end up being negative or greater than one but that is actually fine as long as they end up in the zero to one space again for rendering when converted back to AP0.
If values are stored in integer format in AP0, you will keep the gamut but you lose precision. Because the AP0 gamut is larger than the sRGB gamut, you need more bits to store colour with the same degree of precision. When rendering in a wide gamut, I recommend using floating point for colours whenever possible. Using low dynamic range integer texture formats in sRGB is fine as inputs (normal JPG or PNG textures). Precision loss will be minimal.
Attached are two test renderings. Both of them use the same sRGB 8-bit integer image as input, but one is rendered with ACES primaries and the other with sRGB primaries. Both of them are saved in sRGB. They are a little bit different. This is because the ACES version has rounding errors from having a low precision integer image converted from sRGB to ACES and back, while the sRGB version has less conversion here and there. If floating point colours / textures are used, the precision loss is far less.