I think I may be missing where the answers happened. For instance, I'm not sure where your response to the comment#571 (comment) is - could you please link it here? Thanks so much!

I am copying what I am seeing because I don't understand why it is not visible. The links are embeded:scriptjs started a review
Pending
proposals/add-array-object-feature-option-types.md

Proposed Solution

Extend the Dev Container Feature Options Schema by introducingarray andobject as valid types for feature options. These new types will enable developers to create more complex and customizable features.
Author
@scriptjs scriptjs Pending
Great question! While limiting values to just strings and booleans would keep things simple, supporting arrays and objects actually opens up much more flexibility for feature authors. For example, arrays let you specify lists of packages or ports, and objects make it easy to define key-value pairs—like environment variables or configuration blocks.

Based on the proposal and the examples, the supported value types would include:

strings (for single values, like a name or path),
booleans (for simple on/off options),
arrays (for lists of values, like dependencies or ports), and
objects (for key-value maps, such as sets of environment variables or settings).
This broader support means features can remain simple but also become more powerful, without resorting to awkward workarounds or string parsing. It gives developers the tools they need to create richer, more configurable features, while still allowing for straightforward use cases. If simplicity is a priority, you can always stick to strings and booleans—but having arrays and objects as options makes the schema much more adaptable for everyone!

proposals/add-array-object-feature-option-types.md

Install dependencies

echo "Installing dependencies..."
for package in "${DEPENDENCIES[@]}"; do
Author
@scriptjs scriptjs Pending
While it’s true that using Bash-specific syntax (such as arrays and associative arrays) limits compatibility with minimal shells like /bin/sh, it’s also important to recognize that not all features are public or intended for universal environments. Feature developers should not be restricted to POSIX shell syntax if their use case benefits from Bash’s advanced features.

Allowing Bash syntax gives feature authors more expressive power and flexibility—especially for complex logic, data structures (arrays/objects), and maintainability. The choice of shell should be left to the feature author, depending on their target audience and platform requirements. Imposing strict /bin/sh compatibility on all features can be unnecessarily limiting for those who are able and willing to depend on Bash, or who are building features for environments where Bash is always available.

In summary: while POSIX compatibility is valuable for broad compatibility, there are valid cases where leveraging Bash-specific features is the pragmatic and efficient choice for feature development. Feature authors should be empowered to choose the best tool for their use case.

proposals/add-array-object-feature-option-types.md

Install dependencies

echo "Installing dependencies..."
for package in "${DEPENDENCIES[@]}"; do
Author
@scriptjs scriptjs Pending
Just an addition piece to my comment is that documentation can be enhanced for devcontainers to discuss feature syntax and universality relating to bash use. I know for myself, it's painful for this to be restricted.

proposals/add-array-object-feature-option-types.md

Install dependencies

echo "Installing dependencies..."
for package in "${DEPENDENCIES[@]}"; do
Author
@scriptjs scriptjs Pending
Note, the current feature documentation is below. This confirms what I have indicated about feature developer choice in how features may be developed. While universality may be a goal with minimal shells, authoring is not limited to them. The json schema must match the expressiveness of the goals identified in the documentation. "should" is also not "must" with respect to /bin/sh, and for universality, the default has been expressed in the documentation already. Any deviation should be identified in feature metadata.

Authoring
Features can be authored in a number of languages, the most straightforward being bash scripts. If a Feature is authored in a different language information about it should be included in the metadata so that users can make an informed choice about it.

Reference information about the application required to execute the Feature should be included in devcontainer-feature.json in the metadata section.

Applications should default to /bin/sh for Features that do not include this information.

If the Feature is included in a folder as part of the repository that contains devcontainer.json, no other steps are necessary.

@bamurtaugh All of the pending content is at#571 (comment)

@bamurtaugh I'd appreciate a response so the changes can either be accepted or whether I will have to fork. I made the pull request in April and it is now Aug.

@scriptjs the link you share just brings me to@chrmarti's comment - I don't see your reply. On my end, I still see the same several open review comments without your responses. Could you please share a screenshot here if you see you have replied to these comments, so that we can work on resolving them together? Or could you please try replying again? Thank you!