I can still produce this issue on your branch.

@Jocs
Thanks for checking this.
I verified this against marked's token output:

Input: "- [ ] \n"
raw: "- [ ]"
text: "[ ]"
matches[1]: " "
`[${matches[1]}]`: "[ ]"

Input: "- [x] \n"
raw: "- [x]"
text: "[x]"
matches[1]: "x"
`[${matches[1]}]`: "[x]"

Input: "- [X] \n"
raw: "- [X]"
text: "[X]"
matches[1]: "X"
`[${matches[1]}]`: "[X]"

So the condition is intentional: it verifies that the list item text is exactly the empty task marker and does not contain real task content before rewriting the token as a task-list item.

That said, I agree the inline template expression is easy to misread. I can make it clearer without changing behavior:

const marker = `[${matches[1]}]`;
if (text !== marker)
    return;

I also re-tested the original reported cases on fix/empty-task-list-items with clean files:

- [ ] a
- [ ] 

- [ ] 

- [x] 

All three now render as task-list items with checkboxes in pnpm run dev, and the focused markdownToState tests pass.

If there is another case that still reproduces the issue, please share the exact Markdown input and reproduction steps. I may have missed a different token shape, and I would be happy to add coverage for it.

Follow-up on empty task list items

I checked the incomplete cases on top of fix/empty-task-list-items and found three related gaps.

The first gap is the lazy-continuation shape:

- [ ] 
text

With the current marked token stream, this is not emitted as a task item. It is emitted as a normal list item whose raw source starts with a task marker, while the parsed text starts with the synthetic marker text:

raw:  "- [ ] \ntext"
text: "[ ] \ntext"
task: false

The original fix only handled the empty-only shape where text === "[ ]" or text === "[x]", so it correctly fixed clean empty task items but still rejected this lazy-continuation variant.

The follow-up change keeps the original guard narrow: it only normalizes unordered list items whose raw source starts with a valid task marker and whose parsed text contains the matching synthetic marker prefix. It then strips only that synthetic marker from the token text while preserving the continuation content as the task item's paragraph. Invalid forms such as - [] and - [ ]text still remain normal bullet items.

The second gap is editor rendering. Parser-created empty list items had children: []. That can serialize correctly after the first follow-up, but it is still a bad editable state: a list item with no content descendant has no paragraph/content block for the editor to render or place the caret into. In the desktop editor, this made the source look correct while the visual editor only showed the non-empty task items.

The follow-up now normalizes empty list_item containers to contain an empty paragraph:

children: [{ name: "paragraph", text: "" }]

This matches the existing emptyStates model for bullet/task lists and keeps empty task items visible/editable in the editor.

The third gap is serialization. Programmatic or legacy states can still contain empty list items with children: []. stateToMarkdown previously emitted the item marker but no newline for that case, so consecutive empty items could be serialized as one physical line, for example:

- [ ] - [ ] 

The serializer now returns a complete line for empty list items. This covers both empty task items and plain empty bullet items without changing non-empty list item serialization.

Expected behavior after the follow-up:

- [ ] 
text

is parsed as one unchecked task item with text as its content. Saving may normalize it to:

- [ ] text

which preserves the Markdown semantics.

Regression coverage added:

pnpm --filter @muyajs/core test -- src/state/__tests__/markdownToState.spec.ts
pnpm --filter @muyajs/core test -- src/state/__tests__/listSerialization.spec.ts
pnpm --filter @muyajs/core test -- src/block/gfm/taskListItem/__tests__/emptyTaskItemRender.spec.ts
pnpm --filter @muyajs/core test -- src/state/__tests__/markdownToState.spec.ts src/state/__tests__/listSerialization.spec.ts src/state/__tests__/nestedMixedLists.spec.ts
pnpm --filter @muyajs/core test -- src/block/content/paragraphContent/__tests__/enterListItemEmptyFirst.spec.ts src/block/content/paragraphContent/__tests__/enterHandler.spec.ts src/block/content/paragraphContent/__tests__/backspaceUnwrap.spec.ts src/clipboard/__tests__/pasteListMerge.spec.ts src/state/__tests__/nestedMixedLists.spec.ts
pnpm --filter @muyajs/core exec vitest run --testTimeout 30000
pnpm --filter @muyajs/core lint:types
pnpm --filter @muyajs/core lint
pnpm typecheck
git diff --check HEAD

All passed locally. The lint command only reports existing warnings.

Updated this branch after merging the latest develop.

I also folded the plain empty bullet-list regression coverage from the narrower empty-list PR into this PR, as
suggested. This PR now covers both:

• empty task-list items, including consecutive empty unchecked/checked task items;
• plain empty bullet-list items, including adjacent empty items before a following paragraph and an empty item between
  populated siblings.

While resolving the merge, I also fixed two regressions introduced by the interaction with newer develop changes:

• narrowed the synthetic task-marker detection to spaces/tabs only, so [x] parent from HTML paste is not
  misclassified as a real task-list item;
• updated the [Bug] keyboard navigation issue with lists #4644 arrow-navigation regression to construct a genuinely childless list item directly, because parsed
  empty list items are intentionally preserved as editable empty paragraphs in this PR.

Validation:

pnpm --filter @muyajs/core test -- src/state/__tests__/listSerialization.spec.ts src/state/__tests__/
markdownToState.spec.ts src/block/gfm/taskListItem/__tests__/emptyTaskItemRender.spec.ts src/utils/__tests__/
htmlTaskListPaste.spec.ts src/block/base/__tests__/arrowNavigation.spec.ts
pnpm --filter @muyajs/core exec vitest run --testTimeout 20000
pnpm --filter @muyajs/core lint:types
pnpm --filter @muyajs/core lint