The chosen feature bit for eltoo conflicted with zeroconf channels, suggesting that an alternative identifier should be considered, such as 'L2' in the experimental range. Additionally, there was an overwhelming display of zeros in the "features" field when listing peers through the client, which became cumbersome.

Creating standard non-eltoo channels proved to be dysfunctional, rendering connections to ordinary peers ineffective. While channel creation between two nodes was successful, subsequent actions faced significant hurdles. Payments could not be processed due to an inability to locate a clear path to the recipient peer. Both cooperative and unilateral shutdowns of channels malfunctioned; with cooperative attempts resulting in miscommunication between nodes, and unilateral attempts causing critical failures such as segmentation faults due to null pointer dereferencing.

Restarts of nodes after crashes or intentional stops revealed data integrity issues. The per_commit_remote values stored in the database did not represent valid secp256k1 points, leading to failures upon reloading these values.

Despite these obstacles, progress was made. Transactions related to updates and settlements were successfully broadcasted by manually employing ephemeral anchors, with transaction details accessible via provided links to a mempool explorer. The update transaction was located within logs, and the settlement transaction could be reconstructed using the update transaction's identifier. However, difficulties arose when trying to access private keys necessary for reclaiming funds, which is where the situation currently stands unresolved.