Summary
UEFN — A Two-Day Case Study in Systemic Platform Failure
Author: [PROJECT_NAME] development team, in the role of both player and creator.
Framing: this document treats a single production task — extracting a geographic region of a persistent Fortnite island into its own sub-level asset for use in a map-vote system — as a diagnostic microcosm of Unreal Editor for Fortnite as a platform. Every failure enumerated below was encountered inside this one workflow. The concentration of failure modes in a single, elementary task is the point.
Methodology: only claims with reproducible in-editor evidence, direct API responses, or explicit validator output are included. Speculation is excluded. Where the author overstated during the incident, retractions are marked.
Placeholder legend — substituting my project’s actual names with placeholders:
[PROJECT_NAME]— the UEFN project the author is authoring[PERSISTENT_MAP]— the project’s primary island umap (the persistent world)[REGION_A],[REGION_B],[REGION_C],[REGION_D]— four distinct geographic regions of that primary island the author attempted to extractL_[REGION_A],L_[REGION_B],L_[REGION_C],L_[REGION_D]— the corresponding attempted sub-level asset umaps[hash-path]— a UEFN-generated external actor package hash path of the form<digit>/<chars>/<chars>- Device labels in receipts (
[AudioPlayerDevice],[NPCSpawnerDevice], etc.) — genericized from the actor labels the validator emitted; the class names and internal mesh paths are Epic-owned and identical in every UEFN project
1. The Task and Why It Should Have Been Simple
The task: separate a geographic sub-region of an existing persistent Fortnite island (e.g. the “[REGION_A]” region) into its own sub-level asset, so the region could be surfaced as a selectable map in a map-vote workflow. The persistent island already contains all authored content — buildings, props, devices, cinematics, spawners. Extracting a subset of that content into its own umap is, in every game engine the author has worked in, a routine operation supported by a first-class “Save Region As” or “Move To New Level” tool.
UEFN is Unreal Engine 5 with a Fortnite content overlay. Unreal Engine 5’s native tooling supports region-to-sublevel extraction. A reasonable developer, reading UEFN’s own API surface, would infer this task is straightforward.
It took two days. It never fully succeeded. The reasons why constitute the rest of this document.
2. The Cascade — What Actually Happened, In Order
STAGE 1 — The API surface implies the operation is supported.
UEFN’s Python API exposes EditorLevelUtils.create_new_streaming_level, actor_sub.duplicate_actors(actors, to_world=…), and EditorAssetSubsystem.duplicate_asset. The duplicate_actors signature explicitly documents a to_world parameter with the description: “World to place the duplicated actors in.” Nothing in the API surface, the docs, or the editor UI indicates cross-world duplication of gameplay content is unsupported or restricted.
Pattern: the platform advertises capability it does not deliver.
STAGE 2 — The advertised parameter is silently ignored.
Calling duplicate_actors(sources, to_world=target_world) places the duplicates in the source world regardless of the to_world argument. No exception is raised. No warning is logged. The return value is a valid list of duplicated actors. The only signal that the parameter was ignored is that the destination world’s actor count is unchanged after the call returns.
Pattern: documented API parameters silently do nothing.
STAGE 3 — The workaround appears to succeed. It has not.
The developer reroutes: create a fresh empty sub-level, duplicate actors while the sub-level is loaded as a streaming child of persistent, then use move_actors_to_level to relocate. The count matches. Positions match. Attachments match. The save reports success. The EditorValidatorSubsystem.validate_assets_with_settings call reports invalid: 0, valid: 1.
The developer marks the task complete for the first region ([REGION_A]) and proceeds to extract three more ([REGION_B], [REGION_C], [REGION_D]) using the same recipe.
Only on attempting to open the fourth extracted region does the true validator regime run and surface dozens of AssetValidator_AssetReferenceRestrictions errors that were present in all four sub-levels from the moment of creation.
Sample from the [REGION_D] open-time validator (dozens of errors visible in the log, additional entries truncated): [AudioPlayerDevice] illegally references: /Game/Creative/Devices/Common/Audio/AudioPlayer_Unit_Sphere_14Segs [FixedPointCameraDevice] illegally references: /Game/Creative/Devices/Generic/Meshes/CP_Device_GenericBaseBeam_01 [NPCSpawnerDevice] illegally references: /Game/Creative/Devices/WildLife/Meshes/CP_Device_Wildlife_Cylinder01 [CinematicSequenceDevice] illegally references: /Game/Creative/Devices/Generic/Meshes/CP_Device_GenericBase_01 [CustomizableLightDevice] illegally references: /CRD_PointLight/Creative/Devices/CustomizableLighting/Meshes/CP_Device_CustomizableLighting_01 […the pattern continues for every gameplay device in the extracted region…]
Pattern: save-time validation, manual validation, and open-time validation disagree with each other. No documentation states which is authoritative or when each will run.
STAGE 4 — The engine’s suggested fix destroys the content.
Each validator error is annotated: “Fix: Reset Illegal References to Default.” This action does not resolve the reference restriction meaningfully — it nulls the reference. The device loses its editor preview mesh and any runtime behavior tied to that reference. The engine’s answer to “your reference is not allowed here” is to erase the reference rather than to explain why it is not allowed or what preserves function.
Pattern: error remediation guidance destroys the artifact it claims to repair.
STAGE 5 — Attempting to clean the failed attempt reveals a second class of failure.
Deleting the corrupt sub-level via Content Browser right-click Delete produces a progress bar advancing at approximately ten minutes per one percent of completion. The developer kills the operation and attempts programmatic delete via EditorAssetSubsystem.delete_asset, which returns False with no diagnostic. The editor log’s only relevant line is:
LogEditorAssetSubsystem: Error: DeleteAsset failed: Could not find the source asset. The asset ‘/…/L_[REGION_D].L_[REGION_D]’ exists but was not able to be loaded.
The asset exists on disk. It is registered in the asset registry. It cannot be loaded. It cannot be deleted. It cannot be repaired. The only remediation is disk-level file removal — an operation for which the editor holds file handles that persist beyond unload_packages success and beyond SystemLibrary.collect_garbage(). A full editor restart is required to release the locks.
Pattern: three official routes to accomplish an operation, each fails in a different way, none diagnoses itself, and the reliable path is bypassing the editor entirely at the filesystem level.
STAGE 6 — The unblock requires manual intervention the automation cannot perform.
While the developer is attempting a subsequent save, a modal dialog appears: “The asset ‘…L_[REGION_D]/[hash-path]’ failed to save. Cancel / Retry / Continue.” The modal blocks the editor’s main thread and, consequently, blocks the Python listener. No API dismisses the modal. The developer must physically click a button in the editor UI before any further automation can proceed.
Pattern: the platform pauses automation for manual UI intervention with no programmatic escape.
STAGE 7 — The alternative approach preserves the errors it was supposed to solve.
The developer switches to EditorAssetSubsystem.duplicate_asset on the persistent world, intending to trim the result. This operation preserves all internal references — including the ones that duplicate_actors silently nulled. The result is a sub-level that is functionally more complete but fails validation loudly, as documented in Stage 3. Both approaches produce broken sub-levels; they differ only in whether the breakage is loud or silent.
Pattern: every workaround exchanges one class of failure for another. There is no path that produces a working result.
STAGE 8 — The runtime composition mechanisms that would enable map-vote are blocked, but not all sub-level composition is blocked.
At no point during the two-day cascade did the platform surface the underlying architectural fact relevant to the workflow the developer was building: a sub-level in UEFN cannot be dynamically loaded, unloaded, or promoted to primary at runtime. The map-vote workflow specifically requires runtime map switching, and every UE5 mechanism that would provide it is blocked.
Tested directly and confirmed by the FortValidator_FortExposedAssets validator:
LevelStreamingAlwaysLoadedreference in persistent: blocked.LevelStreamingDynamicreference in persistent: blocked.LevelInstanceactor referencing a sub-level’s World asset in persistent: blocked (persistent save succeeds but validator returnsinvalid: 1, valid: 0).
Persistent save with LevelStreamingAlwaysLoaded reference: Package /…/[PERSISTENT_MAP] references disallowed object /Script/Engine.LevelStreamingAlwaysLoaded. (FortValidator_FortExposedAssets) Persistent validation with LevelInstance actor present (WorldAsset assigned via set_world_asset, no override): validation: checked=1, invalid=1, valid=0, warnings=0
However, one composition mechanism is validator-clean, and this correction is important:
PackedLevelActorreferencing a sub-level’s World asset in persistent: allowed. Persistent save succeeds, full validator returnsinvalid: 0, valid: 1, warnings: 0.
Persistent validation with PackedLevelActor->L_[REGION_A]: validation: checked=1, invalid=0, valid=1, warnings=0
PackedLevelActor is a cook-time static-content bake mechanism. It flattens the referenced sub-level’s static geometry into the actor at build time and instantiates that geometry in persistent at runtime. It is the mechanism creators use for the “author complex static sets in isolated sub-levels, then bring them into persistent” workflow. It supports the iso-authoring use case.
It does not support map-vote or any runtime-switchable-content use case. What gets baked is decided at project cook time, not at player vote time. The referenced sub-level becomes part of persistent from the moment the project is built; there is no runtime switch between different PackedLevelActor targets and no way to defer the bake.
So the honest architectural summary: UEFN permits static, cook-time composition of sub-level content into persistent (via PackedLevelActor). It does not permit dynamic, runtime-switchable, or unload/reload composition of sub-levels by any mechanism. The former is enough for iso-authoring workflows and content organization. The latter is required for map-vote, dynamic gameplay chunk loading, and any other workflow where which sub-level is present is a runtime decision. Only the latter is blocked. The block is total for that use case and not partially recoverable.
Pattern: runtime composition is architecturally forbidden while cook-time composition is permitted, and the docs do not clarify which category any given use case falls into. The developer must probe each API by trial to learn which side of the line it lives on.
STAGE 9 — Even if the sub-level could be played, the persistent world’s content would not be available in it.
Suppose, contrary to Stage 8, the developer found a way to play an extracted sub-level as its own map. The failure regime would not end there. UEFN’s world model treats each world as a closed content boundary. A sub-level played in isolation inherits nothing from the persistent world:
- Verse scripts attached to persistent do not run in the sub-level. Each world has its own Verse device bindings.
- Island Settings — game rules, team layout, spawn configuration, HUD toggles — are per-world. Persistent’s Island Settings do not apply.
- HUD widgets configured in persistent do not display in the sub-level.
- Player spawn pads placed in persistent do not exist for the sub-level.
- The map controller, mode-selection devices, cross-map game logic devices — all persistent-only content — are absent.
- Direct Event Binding wiring between devices in persistent cannot reach devices in the sub-level, and vice versa.
The consequence: if a developer wants their map-vote maps to share any gameplay logic, HUD, ruleset, or Verse code, that content must be authored redundantly in every sub-level. There is no “shared library” world, no inheritance mechanism, no cross-world Verse module scope. A four-map vote system requires four full copies of every gameplay device and every HUD component and every Verse binding.
Combined with Stages 2 through 7 above — which established that cross-world content duplication silently corrupts device references and cinematic bindings — this means the redundant authoring cannot even be automated by copying. It must be re-authored by hand, per map, from scratch. Every map is effectively a separate UEFN project sharing only visual assets.
The persistent world in UEFN is not “persistent” in any meaningful sense across the level system. It is the sole world where gameplay content is architecturally valid. Every other level is a walled sandbox with none of persistent’s rules, none of persistent’s logic, and no supported mechanism to import them. The term “persistent” describes only that this one world is always loaded — not that any of its content endures beyond it.
Pattern: the naming of core concepts implies capabilities the implementation does not deliver. “Persistent level,” “sub-level,” “streaming level,” and “map-vote” all suggest a compositional level system. The platform ships none of the composition.
STAGE 10 — Both remedies are independently sabotaged, so neither is available.
A developer confronting Stages 8 and 9 has two natural fallbacks. Both are separately blocked by the failures already documented above.
- Fallback A: have persistent content stream or follow into the sub-level at runtime so it participates in whichever world is active. Blocked by Stage 8’s runtime-composition restrictions:
LevelStreamingAlwaysLoaded,LevelStreamingDynamic, andLevelInstanceall trigger validator restrictions in persistent. There is no “always-follow” flag, no per-session content scope, no cross-world Verse module — nothing in the platform surface that lets a piece of persistent content accompany the player into another world at runtime. (Note:PackedLevelActoris validator-clean but only performs static cook-time baking, not runtime follow — it does not resolve this fallback.) - Fallback B: give up on stream/follow and just copy the persistent content into each sub-level, accepting the redundancy. Blocked by Stages 2–4: cross-world
duplicate_actorssilently nulls the illegal references gameplay devices depend on;duplicate_asseton the whole world preserves the references but fails open-time validation with dozens ofAssetReferenceRestrictionserrors; and the “Reset Illegal References to Default” remediation erases the reference rather than repairing it.
The two fallbacks are not alternative failure paths of the same restriction — they are two independent sabotages. Streaming is blocked at the validator level in the persistent world. Copying is broken at the actor-duplication API level regardless of the persistent world’s state. A developer who accepts the loss of streaming and pivots to copying encounters an entirely separate set of failures. A developer who accepts the loss of copying and pivots to streaming encounters an entirely separate set of failures. There is no combination of the two that produces a working result.
The composition problem is not “one blocked path with several workarounds.” It is a matrix of blocked paths whose blockages are enforced by different subsystems for different reasons, none of which are documented in relation to each other. Any single blockage would be a serious deficiency; the co-occurrence of both is a structural refusal to let creators compose content across worlds by any means.
Pattern: when the primary path fails, every viable fallback fails for an independent reason. The failure surfaces are not aligned with each other, so no single fix — even a hypothetical Epic-side fix — would restore the workflow. The composition failure is defended in depth.
STAGE 11 — The underlying engine supports the runtime operation. The platform explicitly disables it while permitting only the cook-time variant.
Every runtime-composition failure documented in Stages 8 through 10 could be characterized as a limitation of the engine. That characterization would be false. UEFN is Unreal Engine 5 with a Fortnite content overlay. The underlying engine, in every other UE5 title, supports exactly the runtime operations the developer was attempting:
- UE5 exposes
LoadStreamLevelandUnloadStreamLevelas first-class gameplay functions. These are the standard mechanism by which UE5 games load and unload sub-levels at runtime. - UE5 exposes
LevelStreamingAlwaysLoadedandLevelStreamingDynamicas first-class level streaming classes. - UE5 exposes
LevelInstanceactors for both cook-time and runtime compositional assembly. - UE5 exposes
PackedLevelActorfor cook-time static bake of sub-level content into a single actor. - UEFN inherits and displays all of the above in its editor UI.
Of these, UEFN permits PackedLevelActor only — the cook-time static variant. The three runtime-capable mechanisms (LoadStreamLevel/UnloadStreamLevel, streaming level classes, LevelInstance) are blocked in the runtime by FortValidator_FortExposedAssets, which refuses to allow persistent to save with such a reference. The blocking is selective: cook-time static composition is welcome, runtime dynamic composition is refused.
Persistent save attempt with sub-level streaming reference present: Package /…/[PERSISTENT_MAP] references disallowed object /Script/Engine.LevelStreamingAlwaysLoaded. (FortValidator_FortExposedAssets)
The reason for the block is nowhere documented. Plausible motivations exist — content moderation, publishing manifest requirements, creator sandboxing, runtime memory guarantees — but none of them are stated by the validator, in any documentation available to the creator, in the editor UI, or in any Epic-authored guidance the author has been able to locate. The validator message names the disallowed object class and terminates. It offers no rationale and no alternative.
This is the strongest single indictment in this report. The failure of the map-vote workflow is not the failure of an engine that cannot support it. It is the failure of a platform layer that has taken an engine which does support it and deliberately turned that support off, while continuing to expose the disabled APIs in the editor UI as though they were available. The creator is invited to construct a workflow the platform has already decided not to allow, is given no notice of the decision, and discovers it only by hitting the validator wall.
Pattern: capabilities inherited from the underlying engine are surfaced in the tooling and blocked at runtime by an undocumented policy layer. The developer’s mental model — reasonably built from the UE5 substrate they can see — is invalidated silently and only in production.
3. What This Microcosm Reveals
The pattern above is not accidental. Every stage exhibits the same underlying design choice:
Allow the operation to be attempted. Do not warn. Do not fail early. Report success where honest failure is available. Delay the honest failure to a downstream point where the developer has committed sufficient time that abandoning the work is expensive.
This is not a set of independent bugs. It is a design regime. Each of the following is a specific instance of that regime:
- The
to_worldparameter is documented and ignored, rather than removed or throwing. - Cross-world duplication silently strips illegal references, rather than refusing.
- Save-time validation clears content that open-time validation rejects, rather than converging.
- The Content Browser accepts a delete request it cannot service in a usable timeframe, rather than refusing or fast-pathing.
- An asset can exist in a state where it cannot be loaded and cannot be deleted, rather than one or the other.
- Sub-level extraction succeeds visually while being architecturally forbidden for its stated purpose, rather than being disabled in the UI.
A platform designed by an organization exercising ordinary engineering common sense would fix any one of these on encountering it in production. That all six are simultaneously present, in a workflow a creator would attempt in the first week of production, is evidence of an organization whose stewardship of its developer surface is not merely negligent but structurally indifferent. Whatever priorities the platform’s leadership is optimizing for, developer-facing reliability, honesty, and time-respect are not among them.
4. Broader Failures Observed in the Same Production Window Corroboration
The following failures were also encountered during [PROJECT_NAME] production. Each is independently reproducible and each fits the same regime documented above. They are enumerated briefly here because they broaden the evidence surface beyond the specific sub-level extraction workflow.
4.1 Physics beta toggle relocated without documentation update
The Physics beta feature was moved from Project Settings → Beta Access to Island Settings. Existing documentation and community guides continue to point at the former location. There is no in-editor redirect, no deprecation notice.
4.2 Custom Scene Graph items invisible in Item Granter Device picker
Custom items authored via Scene Graph Entity Prefabs are not selectable in the Item Granter Device’s item picker. The workaround is to grant via Verse using inventory_component.AddItemDistribute(entity). This workaround is not surfaced anywhere in the Item Granter’s UI or docs. Same regime: the natural path silently does not work; the true path is discoverable only by digging.
4.3 FNEC biome pushback volumes are invisible
Epic-provided FNEC Vista biome meshes carry invisible spawn-restriction and player pushback volumes. Placing a spawn pad geometrically inside one of these volumes results in a player who cannot move on spawn. Neither the mesh preview nor any inspector panel indicates the presence of the volume.
4.4 FNEC vehicle blueprint mobility state corruption
A shipped FNEC vehicle blueprint exhibits a mobility state mismatch — its root StaticMeshComponent0 is not marked Static, but a child component is marked Static and cannot attach. Validator emits:
AttachTo: ‘…StaticMeshComponent0’ is not static, cannot attach ‘…_Static’ which is static to it. Aborting.
Workaround requires manual mobility reset after every move, before saving the scene graph point. The bug is pre-existing in shipped Epic content.
4.5 Franchise-specific gameplay powers are player-only but not marked as such in their Hero Device UI
Certain franchise-specific gameplay powers exposed via the Hero Device are player-only. NPCs — including NPCs representing canonical characters that in-fiction possess those powers — cannot fire them. The Hero Device applies to players. This restriction is not stated in the powers’ documentation or in the Hero Device configuration UI. Developers configure the Hero Device on NPCs and observe no runtime effect with no diagnostic.
4.6 Custom playable licensed characters blocked at two layers
Custom playable characters from a licensed franchise are blocked by both brand policy and the engineering surface. The character construction API does not expose the underlying skeletal mesh binding required. A creator cannot ship the licensed content that the marketing surface implies is possible.
4.7 Verse language: undocumented module-scope restrictions
var at module scope is restricted to weak_map. The <private> access specifier does not function at module scope. Neither restriction is stated in the primary language reference. Both are discovered by writing the natural pattern, receiving a compile error, and reverse-engineering the rule.
4.8 Verse language: ToString missing on engine types
player, faction, and related core types do not implement ToString. Debug logging requires custom stringification. Absence is not called out in the type reference.
4.9 Verse language: block-after-colon syntax is not a syntax error message
if (cond): expr on a single line is a compile error. The body after : must be on the next indented line. The compiler error does not name the rule; it is discovered by trial.
5. Conclusion
The two-day extraction task is not remarkable as a bug report. It is remarkable as a compressed sample. Within a single workflow the platform demonstrated: silent API contract violation, inconsistent validation, unusable asset management performance, in-editor modal deadlock of automation, corrupted-but-undeletable assets, silent content destruction as recommended remediation, and an architectural restriction concealed until the developer had committed several hours of work premised on its absence.
Each of these, encountered alone, would be a serious bug. Their co-occurrence in a first-week creator workflow — accompanied by the corroborating failures documented in Section 4, each of which follows the same pattern — indicates that the developer experience of Unreal Editor for Fortnite is not the result of engineering trade-offs made under resource pressure. It is the result of an organization that has not treated developer-facing reliability, error honesty, or time-respect as things worth optimizing for. Over a multi-year window, none of the failure modes documented here have been corrected. That is a leadership signal.
A player-facing product built on this substrate inherits the substrate’s fragility. A creator committing income to this platform is committing to a tooling regime that will consume time on the platform’s failures rather than on the creator’s work. Both audiences deserve better; both are receiving less than a reasonable minimum.
This report is limited by what the author has directly observed and documented to reproducibility. It excludes failure modes the author has encountered but has not captured to that standard. A complete audit would extend the same analysis to the Scene Graph editor, the Verse compiler’s regression history, the character import pipeline, the marketplace publishing surface, and the runtime crash pattern under moderate NPC counts. The pattern documented here would, in the author’s expectation, extend uniformly into each of those surfaces.
What Type of Bug are you experiencing?
Editor
Steps to Reproduce
Use the editor.
Expected Result
This par. is broader discussion not relevant in a technical-reporting way to the series of failures described above, just the basic expectations broken by Epic which has lead to them: Intelligent design choices. Not-severely-substandard-and-senseless UI/X. Responsible, common sense self-flagging and verbose error reporting WHEN IT MATTERS/when it’s common sense to tell the user things. Respecting players and creators. Common sense. Professional level documentation. Giving any attention to the editor whatsoever like it’s not a cornerstone. Fixing anything, ever. Doing anything more than bolting new bits of gold onto a dumpster fire and asking us to be impressed. Not throwing snarky rocks at Unity about their temporarily being sabotaged by letting halfwit marketing bros make calls, from your glass house that will break if you so much as ask it it’s name. Acting like your engineers or leaders have ever used the editor for 5 minutes or have read literally any of these bug reports–I feel like the cool people replying on here are actually trapped underground or AI because 5 min of use of the editor is not apparent in any one of it’s design choices, half-finished things, bugs left for years, basic features completely not working, things that are so bad they cost people days of work and so substandard they make every thing take 10-100x longer than necessary–and at the end of that time you might just find out some dimwit actually just blocked it. Not expecting to outsource game dev to us, give us worthless half-finished tools, and then the company cry about how profits aren’t record-enough or act surprised when smart games aren’t being made with dumb software. Behavior by company leadership that shows any regard for players, creators, or staff, any common sense improvement over time, any reception+comprehension of feedback whatsoever…
Observed Result
None whatsoever. Indistinguishable from blatant sabotage.
My assessments are just observations. I could be wrong about things. Everything is so unnecessarily incoherent, substandard strutting around as different and then superior, exhausting for no enterprise-grade reason I’m not gonna pretend to have made sense of the circus I spent the last two days in. I know what basic, middle school level tasks this editor makes a childish level of incoherent for no reason and is so thoughtless and disrespectful and schizo it usually can’t even be bothered to let you know if it even knows (I see y’all are still deleting creators days’ worth of work with sync despite how that would be an emergency for an enterprise grade product–nice). Not in common sense verbose flagging, not in documentation, not in any professional or enterprise grade format does it let you know until, gotcha. Like it wants you to gaslight yourself as absolutely long as possible–literally its about 50/50 user error or just designed wrong, for any given thing, just enough for infinite gaslighting. This is psyop grade bad. This sort of struggle to do basic things should virtually not be possible for a user; most user errors here are trash UI/X. Nobody does some of these things these ways not cuz you’re better but cuz these are the least common sense or functional ways possible. Copy/pasting, for example. Idk why I’m so heavy handed this is all indefensible.
I can run three cycles of the Matrix itself faster than your trash software can delete a small level, by the way. Why? Absolutely no reason that everyone’s time need to be disrespected so hard your editor takes 10-30 sec to do a TEXT SEARCH on a PC like mine. Shameless clown shoes are all Epic Fail’s Master of Priorities wears. I’m not mad at the actual talent… Something’s gotta give y’all I’d be solo striking. The stuff’s childish. Make sure Tencent’s people bring their own interpreters.
Sorry I can’t fix the tag cuz your forum has tons of bugs still. Still the obnoxious wrong message about editing in another window, and clicking to remove or to add tags both causes all existing tags to be re-added, which also makes the post unpostable with an error about redundant tags (user must start over).
Affects Versions
5.8
Platform(s)
Windows