# \[Call for feedback\] The Long-term Solidity Roadmap

**URL:** <https://forum.soliditylang.org/t/call-for-feedback-the-long-term-solidity-roadmap/3530>\
**Category:** Feedback\
**Created:** [October 21, 2025, 4:57pm UTC](https://forum.soliditylang.org/t/call-for-feedback-the-long-term-solidity-roadmap/3530 "2025-10-21T16:57:13Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![cameel](https://sea1.discourse-cdn.com/flex001/user_avatar/forum.soliditylang.org/cameel/32/34_2.png) [@cameel](https://forum.soliditylang.org/u/cameel)\
**Post date:** [October 23, 2025, 10:01pm UTC](https://forum.soliditylang.org/t/call-for-feedback-the-long-term-solidity-roadmap/3530/5 "2025-10-23T22:01:17Z")

</div>

> [@mudgen](#):
>
> would like to know if there are ideas or plans in Core Solidity, or aspects or ways to leverage Core Solidity for onchain composability, or make EIP-2535 Diamonds easier to implement, etc.

Well, two main things are the custom storage layouts and a delegatecall mechanism.

Layouts (beyond the rudimentary support we already shipped) are work in progress. The implementation part is easy, the main blocker is still the time needed to properly design it to address all use cases. Depending on the demand, that feature may still ship in Classic Solidity (more details will come with the roadmap wishlist).

As for delegatecall - that’s a tough one. We’ve long been dissatisfied with libraries and planning to drop them in the transition. The problem is that a replacement mechanism is still an open question that we’ll have to figure out.

---

_[View the full topic](https://forum.soliditylang.org/t/call-for-feedback-the-long-term-solidity-roadmap/3530)._